7 ms·

What's wrong with stack allocated buffers? They are faster (no malloc/free) and the stack is large enough to hold couple of KiB of data.

jacquesm 12y ago
Dynamically allocated buffers on the stack are somewhat risky, an overflow of that buffer will allow all kinds of nasty things to happen, some of those things can lead to exploits. So if you're reading data from an untrusted source you normally should avoid reading that data into a stack allocated buffer, especially if the code that does the actual reading is not immediately visible from the scope where the buffer is allocated.
- conductor 12y ago
  I agree that in case of buggy code stack allocated buffers are much easier to exploit, but in my post I assumed that the code is secure, i.e. the developer doesn't allow buffer overflows.
  - jacquesm 12y ago
    Yes, everybody always assumes that the code is secure. That's the root cause of the problem.
    - Dewie 12y ago
      To assume that the people behind OpenBSD put protections against that into their C programs is one of the less wild assumptions to entertain.
      - jacquesm 12y ago
        On the contrary, without reviewing the code you call that is the worst possible assumption you could entertain. But hey, why bother reviewing the code you call, the docs say that it is secure and that makes it so, right?
        Dewie 12y ago
        Calm down Jack. I wrote that it's one of the less wild assumptions: not that it's a reasonable assumption. To trust the OpenBSD's code with regards to security is more of a safe bet than trusting a lot of other organization's code. But of course, that's a relative statement: maybe it's still a horrible assumption.
        jacquesm 12y ago
        I'm pretty calm, it's just that I think that a reputation based approach to security is a bad one, especially because it creates a blind spot.
- brohee 12y ago
  You know OpenBSD has been built with stack protection since 2003? It was the first OS to integrate what was then the outside GCC patch ProPolice (it has since been interated in mainline gcc and is the standard -fstack-protector). Given that and the fact httpd is made by people which know and care about the issues you point, there is much street cred to be had exhibiting a buffer overflow on the stack of this program.
  - jacquesm 12y ago
    And no software has ever been ported over to other operating systems or flavours of similar operating systems...
    - theonemind 12y ago
      I don't think they aim for portability, and give valid reasons why they don't. For instance: http://www.openssh.com/?vm=r http://www.openssh.com/?vm=r """ OpenSSH is developed by two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable (adding the "goop") to make it run on many operating systems -- the so-called -p releases, ie "OpenSSH 4.0p1". """ Obviously, I'm quoting from OpenSSH's page here, but I believe it's probably the same philosophy on why they're writing code that relies on the security properties of OpenBSD.
    - agumonkey 12y ago
      It's funny, sounds like a bad transplant.
- tedunangst 12y ago
  I don't think heap overflows are particularly safer than stack overflows. If anything, more dangerous on most systems, since at least stack cookies are fairly common. Heap protection is harder to find.
  - jacquesm 12y ago
    Agreed, so in this particular case I would have allocated those buffers statically but scoped to the function (so outside the heap). Feel free to call me paranoid ;) I'd have added a sentinel as well.
    - tedunangst 12y ago
      Locally scoped statics are still the moral equivalent of globals, and a waiting landmine for anyone who might ever run this code in a multithreaded environment.
      - jacquesm 12y ago
        Yes, that's definitely a problem. But switching from single threading to multi-threading should trigger a complete review of all the underlying code. That's not a trivial change and likely to break very many things if the assumption was that the code would be single threaded. Every data structure would need to be inspected.
    - makomk 12y ago
      Static buffers have even less protections than the stack or the heap. On many Linux and BSD systems, static variables don't even have ASLR applied to them if they're in an executable rather than a library.
      - jacquesm 12y ago
        Yes, because as a rule it is much harder to get execution of arbitrary code out of an overflow in a buffer allocated like that. The protections are there where they are needed most.

jacquesm 12y ago

Dynamically allocated buffers on the stack are somewhat risky, an overflow of that buffer will allow all kinds of nasty things to happen, some of those things can lead to exploits. So if you're reading data from an untrusted source you normally should avoid reading that data into a stack allocated buffer, especially if the code that does the actual reading is not immediately visible from the scope where the buffer is allocated.

conductor 12y ago
I agree that in case of buggy code stack allocated buffers are much easier to exploit, but in my post I assumed that the code is secure, i.e. the developer doesn't allow buffer overflows.
- jacquesm 12y ago
  Yes, everybody always assumes that the code is secure. That's the root cause of the problem.
  - Dewie 12y ago
    To assume that the people behind OpenBSD put protections against that into their C programs is one of the less wild assumptions to entertain.
    - jacquesm 12y ago
      On the contrary, without reviewing the code you call that is the worst possible assumption you could entertain. But hey, why bother reviewing the code you call, the docs say that it is secure and that makes it so, right?
      - Dewie 12y ago
        Calm down Jack. I wrote that it's one of the less wild assumptions: not that it's a reasonable assumption. To trust the OpenBSD's code with regards to security is more of a safe bet than trusting a lot of other organization's code. But of course, that's a relative statement: maybe it's still a horrible assumption.
        jacquesm 12y ago
        I'm pretty calm, it's just that I think that a reputation based approach to security is a bad one, especially because it creates a blind spot.
brohee 12y ago
You know OpenBSD has been built with stack protection since 2003? It was the first OS to integrate what was then the outside GCC patch ProPolice (it has since been interated in mainline gcc and is the standard -fstack-protector). Given that and the fact httpd is made by people which know and care about the issues you point, there is much street cred to be had exhibiting a buffer overflow on the stack of this program.
- jacquesm 12y ago
  And no software has ever been ported over to other operating systems or flavours of similar operating systems...
  - theonemind 12y ago
    I don't think they aim for portability, and give valid reasons why they don't. For instance: http://www.openssh.com/?vm=r http://www.openssh.com/?vm=r """ OpenSSH is developed by two teams. One team does strictly OpenBSD-based development, aiming to produce code that is as clean, simple, and secure as possible. We believe that simplicity without the portability "goop" allows for better code quality control and easier review. The other team then takes the clean version and makes it portable (adding the "goop") to make it run on many operating systems -- the so-called -p releases, ie "OpenSSH 4.0p1". """ Obviously, I'm quoting from OpenSSH's page here, but I believe it's probably the same philosophy on why they're writing code that relies on the security properties of OpenBSD.
  - agumonkey 12y ago
    It's funny, sounds like a bad transplant.
tedunangst 12y ago
I don't think heap overflows are particularly safer than stack overflows. If anything, more dangerous on most systems, since at least stack cookies are fairly common. Heap protection is harder to find.
- jacquesm 12y ago
  Agreed, so in this particular case I would have allocated those buffers statically but scoped to the function (so outside the heap). Feel free to call me paranoid ;) I'd have added a sentinel as well.
  - tedunangst 12y ago
    Locally scoped statics are still the moral equivalent of globals, and a waiting landmine for anyone who might ever run this code in a multithreaded environment.
    - jacquesm 12y ago
      Yes, that's definitely a problem. But switching from single threading to multi-threading should trigger a complete review of all the underlying code. That's not a trivial change and likely to break very many things if the assumption was that the code would be single threaded. Every data structure would need to be inspected.
  - makomk 12y ago
    Static buffers have even less protections than the stack or the heap. On many Linux and BSD systems, static variables don't even have ASLR applied to them if they're in an executable rather than a library.
    - jacquesm 12y ago
      Yes, because as a rule it is much harder to get execution of arbitrary code out of an overflow in a buffer allocated like that. The protections are there where they are needed most.