13 ms·

IOMobileFrameBuffer has seen a lot of vulnerabilities over the years: https://nvd.nist.gov/vuln/detail/CVE-2011-0227 https://nvd.nist.gov/vuln/detail/CVE-2011-

IOMobileFrameBuffer has seen a lot of vulnerabilities over the years: https://nvd.nist.gov/vuln/detail/CVE-2011-0227 https://nvd.nist.gov/vuln/detail/CVE-2011-0227 https://nvd.nist.gov/vuln/detail/CVE-2015-1097 https://nvd.nist.gov/vuln/detail/CVE-2015-1097 https://nvd.nist.gov/vuln/detail/CVE-2015-5843 https://nvd.nist.gov/vuln/detail/CVE-2015-5843 https://nvd.nist.gov/vuln/detail/CVE-2016-4654 https://nvd.nist.gov/vuln/detail/CVE-2016-4654 https://nvd.nist.gov/vuln/detail/CVE-2017-13879 https://nvd.nist.gov/vuln/detail/CVE-2017-13879 https://nvd.nist.gov/vuln/detail/CVE-2018-4335 https://nvd.nist.gov/vuln/detail/CVE-2018-4335

laumars 5y ago
Counting the number of CVEs to measure the security of a piece of software makes as much sense as counting lines of code to measure a developer’s performance.
- okwubodu 5y ago
  Someone breaking into my house 10 times by jiggling the same doorknob a contractor told me they “fixed” would be very concerning.
  - CharlesW 5y ago
    A door would need thousands of doorknobs for that analogy to make sense.
    - okwubodu 5y ago
      No, you would need to admit your current approach is ineffective and replace the door and/or the repairman.
      - laumars 5y ago
        The GPs point is that writing software is a thousand times more complicated than installing a door knob. And frankly I think they’re being generous to you; writing a frame buffer is even more complicated than their estimation.
  - hk__2 5y ago
    > Someone breaking into my house 10 times by jiggling the same doorknob a contractor told me they “fixed” would be very concerning. The complexity is not the same. My grandfather is not questionning my ability to fix his computer that “breaks” once in a while just because I already fixed it the last time.
    - mox1 5y ago
      But the result is the same! I don't care how complex the vulnerability is. The consequences I do.
      - pixl97 5y ago
        Then I recommend you stop using software. Pretty much every operating system has some fun places near its core that are a steady stream of problems.
- malwarebytess 5y ago
  I don't agree with this analogy. It may very well point to a fundamental problem with the design of the software, or in methodologies employed in its development. In this case a reasonable inference could be that Apple's memory safety design principles need some re-examination. Hard to tell without being on the inside.
  - laumars 5y ago
    https://news.ycombinator.com/item?id=27969587 https://news.ycombinator.com/item?id=27969587
- gorgoiler 5y ago
  Maybe. Quantifying your counter argument would help. If one developer writes 90% of the code there is signal in the statistics.
  - laumars 5y ago
    Counting CVEs is a trivially easy argument to debunk. It’s a topic well written about by many open source contributors and security researchers. It’s a topic discussed on here frequently too. And it’s a topic that common sense alone should be able to debunk, should one spend a few minutes thinking about it rationally. However I have written a more in-depth reply about why counting CVEs is meaningless here: https://news.ycombinator.com/item?id=27969587 https://news.ycombinator.com/item?id=27969587
- joebob42 5y ago
  I think the "counterpoint" here is that that makes an amount of sense >0. While it's far from a complete story, and there are plenty of edge cases where it can be misleading, it's also a metric that will tend to bias in the right direction and has a decent relation to what we are trying to measure.
  - laumars 5y ago
    Some researchers get paid per CVE and thus are encouraged to release hundreds of frivolous reports. Some companies publish frivolous ones in order to raise their own profile. Also the software in question is a complicated subsystem to write on a platform that’s guaranteed to get many eyeballs on. So the fact that those CVEs span roughly once per year might also be a demonstration that there are relatively few bugs (if we knew the number of people and time spent researching vs CVEs published then maybe we’d have a more meaningful statistic). CVEs do also demonstrate that active research is happening. There are plenty of common libraries out there that never get audited. Does fewer CVEs mean they’re more secure? Or does it just mean that nobody has checked? Thus on its own, that data is pretty meaningless in terms of deriving a trend. The reason the LoC comparison was made is because measuring lines of code doesn’t tell you how long a developer has spent debugging, reading documentation, or doing other research required. It doesn’t tell you how secure, performant, or even buggy the code is. All it tells you is the number of lines written and literally nothing more can be derived from that figure. Likewise with CVEs submitted.
SheinhardtWigCo 5y ago
iOS is hundreds of millions of lines of C and C++, with immeasurable ways to feed in untrusted inputs. In that setting, it's guaranteed that there will be a constant supply of remotely exploitable memory corruption bugs. The 0-days will continue to drop on a regular basis until OS vendors embrace widespread memory safety as something that's vitally important to more than just a handful of dissidents and journalists. edit: parent comment previously said "Makes me wonder how secure iOS really is", which is what I was responding to.
- zacwest 5y ago
  Is the implication here that Apple doesn't value memory-safety? Why would you say that? Apple have created and embraced an entire language (Swift) around the idea that things like memory safety are important, but you cannot just rewrite an entire operating system overnight into a new language.
  - SheinhardtWigCo 5y ago
    I didn't say that. Their MacGyvered memory-safe iBoot implementation [1] shows that it's at least a consideration and that they're exploring ways to shore up vulnerable components. Swift is not (currently) a viable replacement for C. I'm not saying they should rewrite the entire OS immediately, but: given the pace at which they're able to pump out new marketable features; the massive deployed base of iOS devices; and the sensitivity of the data that is kept on those devices, I would argue that they damn well better have a long-term plan to replace their bug-ridden kernel and other important low-level systems, with code that isn't vulnerable to classes of bugs that have been solved for decades and are frequently exploited in the wild. And I'm not just talking about Apple here. [1] https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web https://support.apple.com/guide/security/memory-safe-iboot-i...
    - danieldk 5y ago
      they damn well better have a long-term plan to replace their bug-ridden kernel and other important low-level systems I think they are slowly going in that direction, e.g. by moving drivers to user space with DriverKit (which AFAIK unfortunately, still uses C++).
brundolf 5y ago
Even the name just sounds like something that would get exploited
marcan_42 5y ago
IOMobileFramebuffer is a massive driver (or rather collection of drivers). These days most of the code runs on a coprocessor called DCP, which I am reverse engineering. The firmware on M1 Macs is 7MB. 7MB to put pixels on screens (this does not include the GPU/rendering). Display controllers are complicated (and Apple ones are especially so, with all their fancy features).

laumars 5y ago

Counting the number of CVEs to measure the security of a piece of software makes as much sense as counting lines of code to measure a developer’s performance.

okwubodu 5y ago
Someone breaking into my house 10 times by jiggling the same doorknob a contractor told me they “fixed” would be very concerning.
- CharlesW 5y ago
  A door would need thousands of doorknobs for that analogy to make sense.
  - okwubodu 5y ago
    No, you would need to admit your current approach is ineffective and replace the door and/or the repairman.
    - laumars 5y ago
      The GPs point is that writing software is a thousand times more complicated than installing a door knob. And frankly I think they’re being generous to you; writing a frame buffer is even more complicated than their estimation.
- hk__2 5y ago
  > Someone breaking into my house 10 times by jiggling the same doorknob a contractor told me they “fixed” would be very concerning. The complexity is not the same. My grandfather is not questionning my ability to fix his computer that “breaks” once in a while just because I already fixed it the last time.
  - mox1 5y ago
    But the result is the same! I don't care how complex the vulnerability is. The consequences I do.
    - pixl97 5y ago
      Then I recommend you stop using software. Pretty much every operating system has some fun places near its core that are a steady stream of problems.
malwarebytess 5y ago
I don't agree with this analogy. It may very well point to a fundamental problem with the design of the software, or in methodologies employed in its development. In this case a reasonable inference could be that Apple's memory safety design principles need some re-examination. Hard to tell without being on the inside.
- laumars 5y ago
  https://news.ycombinator.com/item?id=27969587 https://news.ycombinator.com/item?id=27969587
gorgoiler 5y ago
Maybe. Quantifying your counter argument would help. If one developer writes 90% of the code there is signal in the statistics.
- laumars 5y ago
  Counting CVEs is a trivially easy argument to debunk. It’s a topic well written about by many open source contributors and security researchers. It’s a topic discussed on here frequently too. And it’s a topic that common sense alone should be able to debunk, should one spend a few minutes thinking about it rationally. However I have written a more in-depth reply about why counting CVEs is meaningless here: https://news.ycombinator.com/item?id=27969587 https://news.ycombinator.com/item?id=27969587
joebob42 5y ago
I think the "counterpoint" here is that that makes an amount of sense >0. While it's far from a complete story, and there are plenty of edge cases where it can be misleading, it's also a metric that will tend to bias in the right direction and has a decent relation to what we are trying to measure.
- laumars 5y ago
  Some researchers get paid per CVE and thus are encouraged to release hundreds of frivolous reports. Some companies publish frivolous ones in order to raise their own profile. Also the software in question is a complicated subsystem to write on a platform that’s guaranteed to get many eyeballs on. So the fact that those CVEs span roughly once per year might also be a demonstration that there are relatively few bugs (if we knew the number of people and time spent researching vs CVEs published then maybe we’d have a more meaningful statistic). CVEs do also demonstrate that active research is happening. There are plenty of common libraries out there that never get audited. Does fewer CVEs mean they’re more secure? Or does it just mean that nobody has checked? Thus on its own, that data is pretty meaningless in terms of deriving a trend. The reason the LoC comparison was made is because measuring lines of code doesn’t tell you how long a developer has spent debugging, reading documentation, or doing other research required. It doesn’t tell you how secure, performant, or even buggy the code is. All it tells you is the number of lines written and literally nothing more can be derived from that figure. Likewise with CVEs submitted.

SheinhardtWigCo 5y ago

iOS is hundreds of millions of lines of C and C++, with immeasurable ways to feed in untrusted inputs. In that setting, it's guaranteed that there will be a constant supply of remotely exploitable memory corruption bugs. The 0-days will continue to drop on a regular basis until OS vendors embrace widespread memory safety as something that's vitally important to more than just a handful of dissidents and journalists. edit: parent comment previously said "Makes me wonder how secure iOS really is", which is what I was responding to.

zacwest 5y ago
Is the implication here that Apple doesn't value memory-safety? Why would you say that? Apple have created and embraced an entire language (Swift) around the idea that things like memory safety are important, but you cannot just rewrite an entire operating system overnight into a new language.
- SheinhardtWigCo 5y ago
  I didn't say that. Their MacGyvered memory-safe iBoot implementation [1] shows that it's at least a consideration and that they're exploring ways to shore up vulnerable components. Swift is not (currently) a viable replacement for C. I'm not saying they should rewrite the entire OS immediately, but: given the pace at which they're able to pump out new marketable features; the massive deployed base of iOS devices; and the sensitivity of the data that is kept on those devices, I would argue that they damn well better have a long-term plan to replace their bug-ridden kernel and other important low-level systems, with code that isn't vulnerable to classes of bugs that have been solved for decades and are frequently exploited in the wild. And I'm not just talking about Apple here. [1] https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web https://support.apple.com/guide/security/memory-safe-iboot-i...
  - danieldk 5y ago
    they damn well better have a long-term plan to replace their bug-ridden kernel and other important low-level systems I think they are slowly going in that direction, e.g. by moving drivers to user space with DriverKit (which AFAIK unfortunately, still uses C++).

brundolf 5y ago

Even the name just sounds like something that would get exploited

marcan_42 5y ago

IOMobileFramebuffer is a massive driver (or rather collection of drivers). These days most of the code runs on a coprocessor called DCP, which I am reverse engineering. The firmware on M1 Macs is 7MB. 7MB to put pixels on screens (this does not include the GPU/rendering). Display controllers are complicated (and Apple ones are especially so, with all their fancy features).