7 ms·

I'm probably going to sound painfully naive now... but why is that a security risk? So libbfd reads past the end of a buffer and segfaults.. so what? It's not w

I'm probably going to sound painfully naive now... but why is that a security risk? So libbfd reads past the end of a buffer and segfaults.. so what? It's not writing or executing anything untoward, so who cares?

JoshTriplett 12y ago
Segfaults frequently indicate exploitable security holes, and in particular, the fuzz test shown in the article shows a segfault at a user-controlled address (0x41414141 is AAAA).
deleted 12y ago
[deleted]
pumpkinross 12y ago
Having any segfault is historically a strong indicator that there are worse things you have yet to discover.
- jrockway 12y ago
  Segfault: interesting. Segfault at 0x41414141 when your input is "AAAA": alarming.
jsaxton86 12y ago
Consider the case of a buffer overrun, a vulnerability that can often cause segfaults. A clever attacker could write a bunch of nasty code to that buffer, then use the buffer overrun to insert a jump statement back to that malicious code. Maybe they added the equivalent "rm -rf $HOME`" or something. Or maybe they decided to dial home with a reverse shell on your system. You have no idea, since you have no control over what code is being executed.
- panzi 12y ago
  How will they do this if it's a read buffer overflow, not a writer overflow?
  - eli 12y ago
    Because you control a bunch of memory around that buffer anyway. It's reading a file that you have complete control over, after all. The fact that it crashed at address "41414141" strongly suggests its exploitable. That value is like the "hello world" of testing vulnerabilities.
    - panzi 12y ago
      If something that shouldn't be written is written then yes. But from all the reports it sounds like it just reads something that shouldn't be read and produces a segmentation fault because it reads an unallocated page. I could be wrong about what happens, I haven't looked at it in detail. That is how the news reports sound like to me, so I wonder how could one use that to execute code?
      - eli 12y ago
        To quote the linked article: "The 0x41414141 pointer being read and written by the code comes directly from that proof-of-concept file and can be freely modified by the attacker to try overwriting program control structures."
        panzi 12y ago
        I seem to have overlooked the "and written".
  - zxcdw 12y ago
    A "read buffer" overflow is still nothing but a program reading some form of input and then overwriting the buffer. The target program has to read to somewhere -- namely to the buffer -- and thus it has to write over the boundaries of the buffer. Because the buffer is local to the function, and because the function return address happens to reside at a higher address than the buffer itself, you probably get to overwrite the return address. Thus, after the function is executed, the execution doesn't return to the call-site but to the address you specified. Place your payload code in the buffer you provided, and overwrite the function return address to be the address of your buffer and you might do all sorts of fun things. Spawn a root shell (if suid binary), spawn a reverse shell, execute a kernel exploit to get root etc.
hueving 12y ago
I don't see the vulnerability here either. The current responses to your post don't actually point to any exploitable vulnerability either.
jrockway 12y ago
The security risk is that input from the file that strings is run on ends up in places it shouldn't. One classic place is on the stack; after the random data your function puts on the stack is a bunch of bookkeeping information the compiler puts there, including the address to jump back to when the function returns. If you read user data onto the stack carelessly, you can overwrite the instruction pointer with attacker-controlled data, and the program will return from the function, jump there, and begin executing code. In this case, he was just fuzzing with "AAAAAAAAAAA" and the program ended up at 0x41414141 ("AAAA"), which is alarming. The next step would to be to figure out where the input file is in memory, replace AAAA with that address, and replace the data there with code. Now "strings" is executing CPU instructions that were in the input file. That's bad. Some compilers do workarounds, like putting a canary value between the user data and the compiler data, and checking the canary before returning. Some compilers also randomize the location where things go in memory, so it's harder for an attack to predict that address. Some OSes set certain pages to "not executable", so even if an attacker can jump to that memory address, the CPU won't run code from there. None of these are fixes; just barriers for the determined attacker. (W^X is easy to get around, just call code that's already in the binary legitimately, like execve()!) The fix is to only write to memory you've actually allocated; something the C compiler will not help you with.
- Confusion 12y ago
  > That's bad. To emphasize to the casual reader: 'bad' is a bit of an understatement: it's 'game over'.

JoshTriplett 12y ago

Segfaults frequently indicate exploitable security holes, and in particular, the fuzz test shown in the article shows a segfault at a user-controlled address (0x41414141 is AAAA).

deleted 12y ago

[deleted]

pumpkinross 12y ago

Having any segfault is historically a strong indicator that there are worse things you have yet to discover.

jrockway 12y ago
Segfault: interesting. Segfault at 0x41414141 when your input is "AAAA": alarming.

jsaxton86 12y ago

Consider the case of a buffer overrun, a vulnerability that can often cause segfaults. A clever attacker could write a bunch of nasty code to that buffer, then use the buffer overrun to insert a jump statement back to that malicious code. Maybe they added the equivalent "rm -rf $HOME`" or something. Or maybe they decided to dial home with a reverse shell on your system. You have no idea, since you have no control over what code is being executed.

panzi 12y ago
How will they do this if it's a read buffer overflow, not a writer overflow?
- eli 12y ago
  Because you control a bunch of memory around that buffer anyway. It's reading a file that you have complete control over, after all. The fact that it crashed at address "41414141" strongly suggests its exploitable. That value is like the "hello world" of testing vulnerabilities.
  - panzi 12y ago
    If something that shouldn't be written is written then yes. But from all the reports it sounds like it just reads something that shouldn't be read and produces a segmentation fault because it reads an unallocated page. I could be wrong about what happens, I haven't looked at it in detail. That is how the news reports sound like to me, so I wonder how could one use that to execute code?
    - eli 12y ago
      To quote the linked article: "The 0x41414141 pointer being read and written by the code comes directly from that proof-of-concept file and can be freely modified by the attacker to try overwriting program control structures."
      - panzi 12y ago
        I seem to have overlooked the "and written".
- zxcdw 12y ago
  A "read buffer" overflow is still nothing but a program reading some form of input and then overwriting the buffer. The target program has to read to somewhere -- namely to the buffer -- and thus it has to write over the boundaries of the buffer. Because the buffer is local to the function, and because the function return address happens to reside at a higher address than the buffer itself, you probably get to overwrite the return address. Thus, after the function is executed, the execution doesn't return to the call-site but to the address you specified. Place your payload code in the buffer you provided, and overwrite the function return address to be the address of your buffer and you might do all sorts of fun things. Spawn a root shell (if suid binary), spawn a reverse shell, execute a kernel exploit to get root etc.

hueving 12y ago

I don't see the vulnerability here either. The current responses to your post don't actually point to any exploitable vulnerability either.

jrockway 12y ago

The security risk is that input from the file that strings is run on ends up in places it shouldn't. One classic place is on the stack; after the random data your function puts on the stack is a bunch of bookkeeping information the compiler puts there, including the address to jump back to when the function returns. If you read user data onto the stack carelessly, you can overwrite the instruction pointer with attacker-controlled data, and the program will return from the function, jump there, and begin executing code. In this case, he was just fuzzing with "AAAAAAAAAAA" and the program ended up at 0x41414141 ("AAAA"), which is alarming. The next step would to be to figure out where the input file is in memory, replace AAAA with that address, and replace the data there with code. Now "strings" is executing CPU instructions that were in the input file. That's bad. Some compilers do workarounds, like putting a canary value between the user data and the compiler data, and checking the canary before returning. Some compilers also randomize the location where things go in memory, so it's harder for an attack to predict that address. Some OSes set certain pages to "not executable", so even if an attacker can jump to that memory address, the CPU won't run code from there. None of these are fixes; just barriers for the determined attacker. (W^X is easy to get around, just call code that's already in the binary legitimately, like execve()!) The fix is to only write to memory you've actually allocated; something the C compiler will not help you with.

Confusion 12y ago
> That's bad. To emphasize to the casual reader: 'bad' is a bit of an understatement: it's 'game over'.