4 ms·

Can someone explain to a C/C++ newbie why the iPhone is so vulnerable to overflows? My understanding is that tools exist to check your code and identify overflo

Can someone explain to a C/C++ newbie why the iPhone is so vulnerable to overflows? My understanding is that tools exist to check your code and identify overflow-able areas or general unsafe pointer areas. Am I incorrect here? Also, from a broader point of view - is there any way to perform static code analysis and enumerate all code paths that access sensitive resources? For example, create a graph of functions and search for edges to and from the keychain. If one path ends up in a WebGL content renderer, that’s a vulnerability. I feel like this especially would help you enumerate most exploits and zero-days.

dmoy 7y ago
I'm far from good enough at c/c++ to give you a solid answer here, but basically while yes there are tools that can help, you cannot be 100% protected from issues like this. > is there any way to perform static code analysis and enumerate all code paths that access sensitive resources This starts to get towards something akin to the halting problem. Not exactly, but you can sort of intuit why this doesn't work in practice. The combinatorial explosion kills you.
- saalweachter 7y ago
  I would say that it's also complicated by the fact that it's a design feature for the web browser and various web pages to have access to sensitive information. So the answer to "Is it possible for the web browser to do X?" is going to be "yes" for a wide range of X's.
- UncleMeat 7y ago
  It isn't just combinatorial explosion. The number of paths is infinite. So you must use widening or have a finite abstract domain for ay abstract interpretation.
ndesaulniers 7y ago
Not the iPhone itself but all C and C++ codebases. It's possible to write code in these languages without these bugs, but there's a strong positive correlation between lines of code written in these languages, and this class of bug. Other languages will either insert a check before access (which is overhead) or try to elide it as a compiler optimization. Current static analyses are imprecise, while dynamic analyses require actual execution which can be difficult. Modern research is looking to combine the two. Rather than brute force fuzzing (dynamic analysis), static analyze the source to better mutate the input to a few potentially interesting cases.
- lilyball 7y ago
  > It's possible to write code in these languages without these bugs I would go so far as to say in any non-trivial codebase it's virtually impossible to avoid introducing a bug of this nature. SQLite is probably the codebase that has the highest chance of being safe from this, due to its extremely thorough test suite and amount of fuzzing that's been done, but even that codebase was found to have a significant bug (I forget the details) in one of the optional first-party extensions, as that extension did not have the same rigorous test suite that the SQLite core did. To be clear, when I say thorough test suite, IIRC SQLite's test suite has 3x as many lines of code as the code being tested. And I think there's some sort of instrumentation to ensure the test suite covers every single code path.
  - nojvek 7y ago
    Covering the every single branch of code isn’t enough. One needs to test that every single branch isn’t vulnerable to an overflow attack. It’s kind of testing every possible valid, invalid and malicious input the program can take in. Gets even crazier with race conditions and such. Testing is really hard. And given how many companies skip on testing I am led to believe security is a myth. There’s gonna be someone somewhere with an exploit getting your info.
    - eridius 7y ago
      Yeah, which is why fuzzing is important even with tests covering every code path. And even with that, this is why I simply said that SQLite is probably the codebase that comes the closest, rather than saying it actually is bug-free.
  - maoeurk 7y ago
    > IIRC SQLite's test suite has 3x as many lines of code as the code being tested Actually it has a shocking 662x as many lines of tests as it has code[1]. I agree though, SQLite is an amazing piece of software. [1]: https://sqlite.org/testing.html https://sqlite.org/testing.html
- LorenPechtel 7y ago
professorTuring 7y ago
Basically, managing memory is hard, and usually the way you manage the memory depends and interact in the way the OS manage the memory (so not your error but OS or drivers...). Also, sometimes your design make it difficult to keep track of your memory because you share pointers to different processes and classes and you usually make this interactions to be efficient and fast. Basically, if you are a beginner, building easy things in C/C++, you can stick to the basic rules so you never fall in this kind of traps, but if you are an expert focusing in optimization (or time sensible applications) sometimes you make assumptions or rulesets so "you can't use this class like this", "you can't never pass a pointer with less than 64 bytes allocated", and after a couple of months and some people and hat changing they end up making mistakes...
- saagarjha 7y ago
  > SSOO This might sound somewhat irrelevant, but are you a native Spanish speaker (or typing on a Spanish keyboard)?
  - professorTuring 7y ago
    Yeps, sorry, I meant OS (muscle memory is a bitch...) =)

dmoy 7y ago

I'm far from good enough at c/c++ to give you a solid answer here, but basically while yes there are tools that can help, you cannot be 100% protected from issues like this. > is there any way to perform static code analysis and enumerate all code paths that access sensitive resources This starts to get towards something akin to the halting problem. Not exactly, but you can sort of intuit why this doesn't work in practice. The combinatorial explosion kills you.

saalweachter 7y ago
I would say that it's also complicated by the fact that it's a design feature for the web browser and various web pages to have access to sensitive information. So the answer to "Is it possible for the web browser to do X?" is going to be "yes" for a wide range of X's.
UncleMeat 7y ago
It isn't just combinatorial explosion. The number of paths is infinite. So you must use widening or have a finite abstract domain for ay abstract interpretation.

ndesaulniers 7y ago

Not the iPhone itself but all C and C++ codebases. It's possible to write code in these languages without these bugs, but there's a strong positive correlation between lines of code written in these languages, and this class of bug. Other languages will either insert a check before access (which is overhead) or try to elide it as a compiler optimization. Current static analyses are imprecise, while dynamic analyses require actual execution which can be difficult. Modern research is looking to combine the two. Rather than brute force fuzzing (dynamic analysis), static analyze the source to better mutate the input to a few potentially interesting cases.

lilyball 7y ago
> It's possible to write code in these languages without these bugs I would go so far as to say in any non-trivial codebase it's virtually impossible to avoid introducing a bug of this nature. SQLite is probably the codebase that has the highest chance of being safe from this, due to its extremely thorough test suite and amount of fuzzing that's been done, but even that codebase was found to have a significant bug (I forget the details) in one of the optional first-party extensions, as that extension did not have the same rigorous test suite that the SQLite core did. To be clear, when I say thorough test suite, IIRC SQLite's test suite has 3x as many lines of code as the code being tested. And I think there's some sort of instrumentation to ensure the test suite covers every single code path.
- nojvek 7y ago
  Covering the every single branch of code isn’t enough. One needs to test that every single branch isn’t vulnerable to an overflow attack. It’s kind of testing every possible valid, invalid and malicious input the program can take in. Gets even crazier with race conditions and such. Testing is really hard. And given how many companies skip on testing I am led to believe security is a myth. There’s gonna be someone somewhere with an exploit getting your info.
  - eridius 7y ago
    Yeah, which is why fuzzing is important even with tests covering every code path. And even with that, this is why I simply said that SQLite is probably the codebase that comes the closest, rather than saying it actually is bug-free.
- maoeurk 7y ago
  > IIRC SQLite's test suite has 3x as many lines of code as the code being tested Actually it has a shocking 662x as many lines of tests as it has code[1]. I agree though, SQLite is an amazing piece of software. [1]: https://sqlite.org/testing.html https://sqlite.org/testing.html
LorenPechtel 7y ago

professorTuring 7y ago

Basically, managing memory is hard, and usually the way you manage the memory depends and interact in the way the OS manage the memory (so not your error but OS or drivers...). Also, sometimes your design make it difficult to keep track of your memory because you share pointers to different processes and classes and you usually make this interactions to be efficient and fast. Basically, if you are a beginner, building easy things in C/C++, you can stick to the basic rules so you never fall in this kind of traps, but if you are an expert focusing in optimization (or time sensible applications) sometimes you make assumptions or rulesets so "you can't use this class like this", "you can't never pass a pointer with less than 64 bytes allocated", and after a couple of months and some people and hat changing they end up making mistakes...

saagarjha 7y ago
> SSOO This might sound somewhat irrelevant, but are you a native Spanish speaker (or typing on a Spanish keyboard)?
- professorTuring 7y ago
  Yeps, sorry, I meant OS (muscle memory is a bitch...) =)