Let's put a Band-aid on that Gunshot Wound


  • BINNED

    Continuing the discussion from The Quixotic Ideas Thread:

    @ben_lubar said:

    a language that isn't so terrible that it needs ASLR to be secure.

    Your code has a buffer overflow that allows users to write arbitrary data to a known fixed location. So what do you do? Fixing the code (or using a programming language that doesn't allow buffer overflows) is for lusers. There's a much better way: make it so that users write arbitrary data to a random location instead. What could possibly go wrong?

    Here's a thread for cosmetic "solutions" that appear to address the symptom but do nothing to address the root cause.


  • FoxDev

    @antiquarian said:

    There's a much better way: make it so that users write arbitrary data to a random location instead.

    bad code will always happen, i see ASLR more as a "it's a spiderweb of a safety net, but at least when you fuck up it's probably not going to be reliably exploitable, now go and fix your code so you don't need that safety net."

    of course others see it as "ooh i tick this box and i'm secure without doing any actual work? SCORE!"


  • FoxDev

    ASLR solves a lot more than buffer overflow though; it also makes it a lot harder to maliciously inject into a running process, since you never really know where to thrust your big pointy stick


  • BINNED

    Or you could use Ada: the chastity belt of software development.



  • I thought this topic was going to be about this news story:



  • @antiquarian said:

    Here's a thread for cosmetic "solutions" that appear to address the symptom but do nothing to address the root cause.

    Prisons? most of the time anyways



  • @antiquarian said:

    Or you could use Ada: the chastity belt of software development.

    Doesn't stop miscreants with a process handle, CreateRemoteThread, and LoadLibrary from force-feeding your process with their code.


  • BINNED

    @tarunik said:

    Doesn't stop miscreants with a process handle, CreateRemoteThread, and LoadLibrary from force-feeding your process with their code.

    If they can do that, the Ada program is the least of your worries.





  • @tarunik said:

    Doesn't stop miscreants with a process handle, CreateRemoteThread, and LoadLibrary from force-feeding your process with their code.

    Airtight hatchway.

    @ben_lubar said:

    http://blogs.msdn.com/b/oldnewthing/archive/2015/04/22/10609035.aspx

    ... yes that.



  • @blakeyrat said:

    Airtight hatchway.

    Yeah, 'tis not the language's job to provide. The OS is supposed to be able to provide an inter-process airtight hatchway if it's set up to do so, but sometimes it springs little leaks, and bestworst practice until recently was to defeat at least some of the features needed for the OS to provide that airtight hatchway.



  • Here's the thing... if you're out in the wilderness and someone gets shot and all you have is a bandaid, if that bandaid actually covers the wound it's still helpful.

    The term I think best characterizes things like ASLR is "exploit mitigations", because I think that name does a good job of explaining what it does. DEP/NX/W⊕X and stack canaries also fall under this banner. They don't address the underlying problem (the only time they come into play is when there is already a vulnerability), but that doesn't mean they're not helpful. DEP and stack canaries in particular, in one relation or another, significantly change the security landscape and make things much harder for attackers; most bugs that would have been trivial to exploit without either become very difficult and, in some cases, impossible to exploit with one or both. (The proportion of stack corruption vulnerabilities that result in remote code execution exploits in Windows, for example has been cut from about 40% to 5% of the RCE exploits from the Windows 2000 to Windows 7.) This is despite the fact that none of these protections is absolute and they can all be bypassed in some cases; the point is that they raise the bar.

    Furthermore:

    • They are things the OS can do without application involvement. MS can't fix third-party code so it doesn't have buffer overrun vulnerabilities or rewrite it in another language, but it can apply a DEP and ASLR policy that will not break a significant majority of programs and will increase protections for those programs.
    • They have very low overhead for existing programs
    • They do not require an expenditure of an incredible amount of money to rewrite things

    Yes, the situation sucks, and in my less charitable moments I think people who write security-critical software in C or C++ are not only nuts but actually irresponsible. But there's not a remotely-realistic way to arrive at a significantly better state in the near- or mid-term future.



  • @EvanED said:

    The term I think best characterizes things like ASLR is "exploit mitigations", because I think that name does a good job of explaining what it does. DEP/NX/W⊕X and stack canaries also fall under this banner

    Definitely -- they force you from the obvious script kiddie territory of "shove shellcode and nop sled into buffer and go" into having to understand ROP, which is a fair bit harder to pull off (although I do recall reading once about efforts to create an auto-exploit-generator of sorts -- you fed it an exploitable program suitably wrapped, and it'd figure out a lot of the key bits of getting from "this crashes the program" to "somewhat reliable proof of concept", which is useful if only to drill the importance of fixing potential vulns into the skulls of PHBs).

    @EvanED said:

    Yes, the situation sucks, and in my less charitable moments I think people who write security-critical software in C or C++ are not only nuts but actually irresponsible.

    I agree -- we need a better systems language. I'm hopeful that some of the ideas behind Rust will catch on in future language design efforts, myself...because until we get a memory-safe systems (note: not application, systems -- it has to be suitable for writing OS kernels, bootloaders, low-level hardware-grubbing device drivers, firmware, and deeply embedded apps in in order to be a C/C++ replacement in my mind) language, we're going to be stuck in this quagmire forevermore.



  • This is a pattern in so many places it's not funny anymore

    * 23 * * * /opt/restart_servers
    


  • This is even a pattern in Java-land...which is sad. :/



  • @tarunik said:

    we need a better systems language.

    I suggest https://golang.org/



  • The servers must be running on Windows hardware.


Log in to reply