5 ms·

I'll never not be impressed by the people who can find stuff like this

thanatos519 5y ago
I'm doubly impressed by the clarity of the explanation.
pjmlp 5y ago
1 - access to source code 2 - grep for string, arrays and memory functions from C 3 - even if you are not a security expert, maybe you will be able to find out some possibilities
- ghoward 5y ago
  This is entirely reductive. I have written a substantial enough C codebase used in the real world that uses C string handling functions. I did that because the codebase needed zero dependencies other than libc. Yet as far as anyone who's looked at the code can tell, there are no vulnerabilities because I learned how to use realloc() and grow the allocation if needed before calling the string handling functions. It's not hard; it's just busywork.
  - pjmlp 5y ago
    Has the code been fuzzed and subject to static analysis as well?
    - ghoward 5y ago
      Yes. Absolutely. [1] I use scan-build, but I also used to use Coverity until they had that vulnerability a few months back. [1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/development.md#user-content-fuzzing-1 https://git.yzena.com/gavin/bc/src/branch/master/manuals/dev...
goodpoint 5y ago
Find stuff and give it away for very little money. Such vuln could sell for much more.
- jcims 5y ago
  The access I have at work is extremely valuable in that same market. Should I sell that too?
  - kevincox 5y ago
    "Should"? Morally no. But you could likely make a lot of money if you found the right buyer.
- Thaxll 5y ago
  I'm sure a security eng at Google earns more that enough.
- queuebert 5y ago
  Don't forget to subtract the cost of your criminal trial defense.
  - goodpoint 5y ago
    What criminal trial? Security research is perfectly legal to perform and to compensate.
josefx 5y ago
Open C source file, read five minutes, done. The existence of C style strings by itself already guarantees that any C code will be 50% memory access exploits. Sadly instead of adopting one of hundreds sane string types that have been around as long as C if not longer the C standards committee only did the the C equivalent of my_sql_real_escape_string by introducing dozens of overloads that let you specify a "string size" yourself, without any ability to ensure that the provided size is correct. The only good thing about that is that they cannot mess up anything else while they work on the C standard.
- ghosty141 5y ago
  >read five minutes, done. I mean it's obviously harder... I agree with the point you're making but finding an exploit like this is way harder than just "reading the source for 5 minutes".
- vsareto 5y ago
  You're not just finding functions, but also how to affect memory, bypass security controls, and many other things to get a stable exploit I kinda feel like you the other poster suggesting to just search source code learned basic buffer overflows from the 90s and called it a day
  - pjmlp 5y ago
    In general and not talking about the Linux kernel, you would be surprised how much enterprise code, written is C, is susceptible to basic buffer overflows from the 90s. Specially because the people that wrote it use basic C coding patterns and tooling from the 90s. Or do you think the 70% comes all from highly technically hard code to exploit?

I'm doubly impressed by the clarity of the explanation.

1 - access to source code 2 - grep for string, arrays and memory functions from C 3 - even if you are not a security expert, maybe you will be able to find out some possibilities

ghoward 5y ago
This is entirely reductive. I have written a substantial enough C codebase used in the real world that uses C string handling functions. I did that because the codebase needed zero dependencies other than libc. Yet as far as anyone who's looked at the code can tell, there are no vulnerabilities because I learned how to use realloc() and grow the allocation if needed before calling the string handling functions. It's not hard; it's just busywork.
- pjmlp 5y ago
  Has the code been fuzzed and subject to static analysis as well?
  - ghoward 5y ago
    Yes. Absolutely. [1] I use scan-build, but I also used to use Coverity until they had that vulnerability a few months back. [1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/development.md#user-content-fuzzing-1 https://git.yzena.com/gavin/bc/src/branch/master/manuals/dev...

goodpoint 5y ago

Find stuff and give it away for very little money. Such vuln could sell for much more.

jcims 5y ago
The access I have at work is extremely valuable in that same market. Should I sell that too?
- kevincox 5y ago
  "Should"? Morally no. But you could likely make a lot of money if you found the right buyer.
Thaxll 5y ago
I'm sure a security eng at Google earns more that enough.
queuebert 5y ago
Don't forget to subtract the cost of your criminal trial defense.
- goodpoint 5y ago
  What criminal trial? Security research is perfectly legal to perform and to compensate.

josefx 5y ago

Open C source file, read five minutes, done. The existence of C style strings by itself already guarantees that any C code will be 50% memory access exploits. Sadly instead of adopting one of hundreds sane string types that have been around as long as C if not longer the C standards committee only did the the C equivalent of my_sql_real_escape_string by introducing dozens of overloads that let you specify a "string size" yourself, without any ability to ensure that the provided size is correct. The only good thing about that is that they cannot mess up anything else while they work on the C standard.

ghosty141 5y ago
>read five minutes, done. I mean it's obviously harder... I agree with the point you're making but finding an exploit like this is way harder than just "reading the source for 5 minutes".
vsareto 5y ago
You're not just finding functions, but also how to affect memory, bypass security controls, and many other things to get a stable exploit I kinda feel like you the other poster suggesting to just search source code learned basic buffer overflows from the 90s and called it a day
- pjmlp 5y ago
  In general and not talking about the Linux kernel, you would be surprised how much enterprise code, written is C, is susceptible to basic buffer overflows from the 90s. Specially because the people that wrote it use basic C coding patterns and tooling from the 90s. Or do you think the 70% comes all from highly technically hard code to exploit?