9 ms·

Is this another backdoor or am I being paranoid again cause this type of exploit is like those who see in the movies, we start laughing ironically and we are li

Is this another backdoor or am I being paranoid again cause this type of exploit is like those who see in the movies, we start laughing ironically and we are like "cmon now, that's insane...hack every phone using an image, not in a billion"

closeparen 8y ago
It’s notoriously hard to make parsers bulletproof against malicious input. For a toy example, imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? Now you’ve got a remote buffer overflow. How about [start sentinel byte] [up to N data bytes] [end sentinel byte]? Just put more than the allowed bytes before the end sentinel. Unless a format is designed to facilitate secure implementation (which would include being very simple), there are going to be at least a few vulnerable implementations. Is it a backdoor? Read the patch yourself, decide whether the original authors and reviewers knew what they were doing.
- nineteen999 8y ago
  > For a toy example, imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? Now you’ve got a remote buffer overflow. Well then you're doing it wrong. You copy [number of bytes to come] bytes, not [rest of message] size bytes, only once you've validated that [rest of message size] is not too large to begin with. That is a completely toy example. A decent programmer would never trust the remote end to actually just send [number of bytes to come] bytes.
  - deleted 8y ago
    [deleted]
  - jchw 8y ago
    >A decent programmer would never trust the remote end to actually just send [number of bytes to come] bytes. Well, I applaud your optimism, anyways, but programmers of almost any skill level make egregious security mistakes, especially when working on a deadline. Maybe not everyone would make this mistake, but managing trust while writing optimal code is very tricky. LZO is a fantastic example of a library that had an "obvious" security flaw for many years, with a fairly trivial integer overflow bug, due to how the decoder dealt with the variable length int encoding.
  - ajross 8y ago
    > A decent programmer would never [...] And that kind of attitude is why we still have security bugs.
    - nineteen999 8y ago
      > And that kind of attitude is why we still have security bugs. Absolutely poppycock. We could all program in completely memory safe languages tomorrow with only one signed integer type and crap programmers would still find a way to write security holes into their programs. I'm in no way condoning the use of C/C++ forever, the writing is on the wall for those languages, as much as I love them. But programmers have to learn first and foremost to take responsibility; if you're writing code that runs with elevated privileges then BE CAREFUL. If you're writing code that is reading data from an untrusted source (disk, network or otherwise) then BE CAREFUL. Hell, being careful even if you think the data source can be trusted is a good starting point - defensive programming 101. We cannot blame our tools forever, but we can improve them.
      - jononor 8y ago
        "Be careful" is not very actionable. Here are some things you can actually do: - Perform periodic external security reviews - Use fuzzing for all uncontrolled/user-inputs - Use static analysis tools - Maintain a security bounty program - Send your employees to security training - Use a memory safe programming language
        nineteen999 8y ago
        That is a nice list and all, and I would add that if you can't use a memory safe programming language then you should look closely at the compiler flags in use as well. But if you need all that to spot the obvious issue in the OP's original specification ... then wow.
        pas 8y ago
        I'd add the "adopt an information theoretic approach" to security analysis. (Which is basically what taint analyzers perform.) Think through how systems/components/libraries/functions can and do interface with each other, and try to secure these points. (Make them type safe, make them strict, report meaningful errors ["expected this but got this" is a million times better than invalid input], so they will be easy to maintain and make even more secure.) Try to extract out these parameters as much as possible so you can avoid possible impedance mismatches across the interfaces. Also, checklists. Checklists are good. And an inventory of used components, and their versions. (This makes it easy to do a CVE review from time to time, and then to automate the review eventually, so only the list maintenance will remain manual.) Defense in depth, but not through obscurity. (There usually are low hanging fruits. Enforce use of password managers, invest in centralized credential storage, don't overdo password expiration and 2FA. Security training is also a good idea, but the real goal is to nurture a security aware office/team culture.) Social engineering [or just plain old laziness] is still a serious threat. Timeboxing. Set aside 1-2 days every month to work on meaningful security-conscious goals. So try to upgrade to lay the fundamentals for that library upgrade that is overdue for years, try to make systems reproducible (also good for DR), try to add a few simple validations here and there against local file inclusion (or whatever comes up during the month, or during the checklist review). Also, accepting that maintaining network facing systems have an inherent ongoing cost. (Unless you want your iToaster to eventually end up as part of a botnet.) Sometimes we have to let things go, accept that some business models (or hobbyist projects) are not worth it to do sanely and securely.
  - Godel_unicode 8y ago
    > A decent programmer would never... You might want to Google for ImageTragick. Or heartbleed. Or shell shock. Or Java deserialization. Or flash. But please, tell me more about what a decent programmer would never do.
    - nineteen999 8y ago
      You and I evidently have different definitions of "decent programmer" then. It sounds like your standards are much lower.
      - lagadu 8y ago
        Unless by "decent programmer" you mean a non-human programmer, he's right. This might be shocking to a flawless supercomputer AI such as yourself but humans make mistakes.
        nineteen999 8y ago
        Look back at how the original problem is specified. > imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? If your client came to you and said that was the specification, you'd be negligent to fail to point out the obvious flaw with the logic, wouldn't you?
        Gaelan 8y ago
        IIRC Heartbleed was basically exactly that.
        nineteen999 8y ago
        Heartbleed triggered a major audit and a fork (LibreSSL) of the OpenSSL codebase, wherein much of the code was found to be of less than stellar quality: "Unfortunately, the OpenSSL basket was being watched somewhat less than very carefully. Yeah, it has bugs, but surely somebody else will fix them. And worst case scenario, since everybody uses the same library, everybody will be affected by the bugs. Nobody wants to be alone". https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html So I'm pretty sure the one example you have picked here reinforces my point.
  - tokyodude 8y ago
    No, decent programmers know that no one is perfect and so they design systems so that even when the most experienced programmers ever make a mistake that mistake is less likely to cause an exploit. This is the entire premise of Chrome's architecture. Check the CVEs and you'll see there's the same number of bugs as every other browser but around 10x less code exploits because it's designed under the premise that bugs happen.
    - nineteen999 8y ago
      A decent programmer or team of programmers can select a good architecture, and also not pretend that it is okay to treat a 4096-byte buffer as if it were 4097 bytes long.
    - pas 8y ago
      Chrome did the as fast as they could sandboxing because they has no better alternative, because we lack better libraries for parsing. Decent programmers also try to err on the side of safety, use the right tool for the job, and so on. And writing parsers should not be done directly, instead the parser code should be generated by a battle tested library/framework. (Or via using parser combinators, etc.)
- fulafel 8y ago
  Well, it's hard only if you do it in hard mode (in hand-written C/C++), just like bulletproof anything is hard there. We (as a field) have for decades known how to do it safely, people just elect to do it unsafely because of the usual reasons.
  - closeparen 8y ago
    There is a decent argument that line of business apps in unmanaged languages are taking silly risks, but this is the operating system. If the platform has already spent the processing power, application developers are going to be pretty constrained.
madeofpalk 8y ago
IIRC, one of the first iPhone jailbreaks used malformed images as an attack vector to get root.
- fmj 8y ago
  There was an image based exploit for the PSP as well.
  - birdiesanders 8y ago
    PNG as well, iirc
- davis 8y ago
  Yup, it was TIFF in the iPhone case
aboutruby 8y ago
There has been remote control by viewing a web page (classic), a pdf, a word document, receiving a text message, just being connected to the internet, etc. And that's just the beginning, then comes all the indirect attacks like stealing your domain, phone number, identity for loans, etc etc
cjbprime 8y ago
Yeah, I'd say this is paranoid -- it turns out that file format decoders have been extremely insecure forever, and Google's been doing more than anyone to advance the fuzzing of public libraries to fix it. If they wanted to put a backdoor somewhere, they would not put it somewhere where their own automated tools that would detect and publish it.

closeparen 8y ago

It’s notoriously hard to make parsers bulletproof against malicious input. For a toy example, imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? Now you’ve got a remote buffer overflow. How about [start sentinel byte] [up to N data bytes] [end sentinel byte]? Just put more than the allowed bytes before the end sentinel. Unless a format is designed to facilitate secure implementation (which would include being very simple), there are going to be at least a few vulnerable implementations. Is it a backdoor? Read the patch yourself, decide whether the original authors and reviewers knew what they were doing.

nineteen999 8y ago
> For a toy example, imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? Now you’ve got a remote buffer overflow. Well then you're doing it wrong. You copy [number of bytes to come] bytes, not [rest of message] size bytes, only once you've validated that [rest of message size] is not too large to begin with. That is a completely toy example. A decent programmer would never trust the remote end to actually just send [number of bytes to come] bytes.
- deleted 8y ago
  [deleted]
- jchw 8y ago
  >A decent programmer would never trust the remote end to actually just send [number of bytes to come] bytes. Well, I applaud your optimism, anyways, but programmers of almost any skill level make egregious security mistakes, especially when working on a deadline. Maybe not everyone would make this mistake, but managing trust while writing optimal code is very tricky. LZO is a fantastic example of a library that had an "obvious" security flaw for many years, with a fairly trivial integer overflow bug, due to how the decoder dealt with the variable length int encoding.
- ajross 8y ago
  > A decent programmer would never [...] And that kind of attitude is why we still have security bugs.
  - nineteen999 8y ago
    > And that kind of attitude is why we still have security bugs. Absolutely poppycock. We could all program in completely memory safe languages tomorrow with only one signed integer type and crap programmers would still find a way to write security holes into their programs. I'm in no way condoning the use of C/C++ forever, the writing is on the wall for those languages, as much as I love them. But programmers have to learn first and foremost to take responsibility; if you're writing code that runs with elevated privileges then BE CAREFUL. If you're writing code that is reading data from an untrusted source (disk, network or otherwise) then BE CAREFUL. Hell, being careful even if you think the data source can be trusted is a good starting point - defensive programming 101. We cannot blame our tools forever, but we can improve them.
    - jononor 8y ago
      "Be careful" is not very actionable. Here are some things you can actually do: - Perform periodic external security reviews - Use fuzzing for all uncontrolled/user-inputs - Use static analysis tools - Maintain a security bounty program - Send your employees to security training - Use a memory safe programming language
      - nineteen999 8y ago
        That is a nice list and all, and I would add that if you can't use a memory safe programming language then you should look closely at the compiler flags in use as well. But if you need all that to spot the obvious issue in the OP's original specification ... then wow.
      - pas 8y ago
        I'd add the "adopt an information theoretic approach" to security analysis. (Which is basically what taint analyzers perform.) Think through how systems/components/libraries/functions can and do interface with each other, and try to secure these points. (Make them type safe, make them strict, report meaningful errors ["expected this but got this" is a million times better than invalid input], so they will be easy to maintain and make even more secure.) Try to extract out these parameters as much as possible so you can avoid possible impedance mismatches across the interfaces. Also, checklists. Checklists are good. And an inventory of used components, and their versions. (This makes it easy to do a CVE review from time to time, and then to automate the review eventually, so only the list maintenance will remain manual.) Defense in depth, but not through obscurity. (There usually are low hanging fruits. Enforce use of password managers, invest in centralized credential storage, don't overdo password expiration and 2FA. Security training is also a good idea, but the real goal is to nurture a security aware office/team culture.) Social engineering [or just plain old laziness] is still a serious threat. Timeboxing. Set aside 1-2 days every month to work on meaningful security-conscious goals. So try to upgrade to lay the fundamentals for that library upgrade that is overdue for years, try to make systems reproducible (also good for DR), try to add a few simple validations here and there against local file inclusion (or whatever comes up during the month, or during the checklist review). Also, accepting that maintaining network facing systems have an inherent ongoing cost. (Unless you want your iToaster to eventually end up as part of a botnet.) Sometimes we have to let things go, accept that some business models (or hobbyist projects) are not worth it to do sanely and securely.
- Godel_unicode 8y ago
  > A decent programmer would never... You might want to Google for ImageTragick. Or heartbleed. Or shell shock. Or Java deserialization. Or flash. But please, tell me more about what a decent programmer would never do.
  - nineteen999 8y ago
    You and I evidently have different definitions of "decent programmer" then. It sounds like your standards are much lower.
    - lagadu 8y ago
      Unless by "decent programmer" you mean a non-human programmer, he's right. This might be shocking to a flawless supercomputer AI such as yourself but humans make mistakes.
      - nineteen999 8y ago
        Look back at how the original problem is specified. > imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? If your client came to you and said that was the specification, you'd be negligent to fail to point out the obvious flaw with the logic, wouldn't you?
        Gaelan 8y ago
        IIRC Heartbleed was basically exactly that.
        nineteen999 8y ago
        Heartbleed triggered a major audit and a fork (LibreSSL) of the OpenSSL codebase, wherein much of the code was found to be of less than stellar quality: "Unfortunately, the OpenSSL basket was being watched somewhat less than very carefully. Yeah, it has bugs, but surely somebody else will fix them. And worst case scenario, since everybody uses the same library, everybody will be affected by the bugs. Nobody wants to be alone". https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html So I'm pretty sure the one example you have picked here reinforces my point.
- tokyodude 8y ago
  No, decent programmers know that no one is perfect and so they design systems so that even when the most experienced programmers ever make a mistake that mistake is less likely to cause an exploit. This is the entire premise of Chrome's architecture. Check the CVEs and you'll see there's the same number of bugs as every other browser but around 10x less code exploits because it's designed under the premise that bugs happen.
  - nineteen999 8y ago
    A decent programmer or team of programmers can select a good architecture, and also not pretend that it is okay to treat a 4096-byte buffer as if it were 4097 bytes long.
  - pas 8y ago
    Chrome did the as fast as they could sandboxing because they has no better alternative, because we lack better libraries for parsing. Decent programmers also try to err on the side of safety, use the right tool for the job, and so on. And writing parsers should not be done directly, instead the parser code should be generated by a battle tested library/framework. (Or via using parser combinators, etc.)
fulafel 8y ago
Well, it's hard only if you do it in hard mode (in hand-written C/C++), just like bulletproof anything is hard there. We (as a field) have for decades known how to do it safely, people just elect to do it unsafely because of the usual reasons.
- closeparen 8y ago
  There is a decent argument that line of business apps in unmanaged languages are taking silly risks, but this is the operating system. If the platform has already spent the processing power, application developers are going to be pretty constrained.

madeofpalk 8y ago

IIRC, one of the first iPhone jailbreaks used malformed images as an attack vector to get root.

fmj 8y ago
There was an image based exploit for the PSP as well.
- birdiesanders 8y ago
  PNG as well, iirc
davis 8y ago
Yup, it was TIFF in the iPhone case

aboutruby 8y ago

There has been remote control by viewing a web page (classic), a pdf, a word document, receiving a text message, just being connected to the internet, etc. And that's just the beginning, then comes all the indirect attacks like stealing your domain, phone number, identity for loans, etc etc

cjbprime 8y ago

Yeah, I'd say this is paranoid -- it turns out that file format decoders have been extremely insecure forever, and Google's been doing more than anyone to advance the fuzzing of public libraries to fix it. If they wanted to put a backdoor somewhere, they would not put it somewhere where their own automated tools that would detect and publish it.