Hacker News Reader

Comment by rfoo | Hacker News Reader

There are more than one billion lines of C code which hasn't been updated in the last decade and is still in use.

Who is going to update these code once the "do the right thing"-compiler become available?

Oh, and the worst part: some of them may already be bug-free due to 15 years (if not more) of people trying to make money by selling exploits to surveillance vendors or who knows. But there's certainly high-impact bugs left. Now what, refactor the code to use the fancy eliminate-spatial-memory-corruption C variant and introduce a few UAF by the way?

View on HN

The authors and maintainers of that code. Any error or warning flagged by this change is something that really ought to be changed anyway because any unchecked array or pointer dereference is a potential security risk.

Have you read the source code of Xpdf (the thing being exploited in the famous NSO Apple iMessage 0-click blah blah)?

I did (because I wrote an exploit for the bug after the Google blogpost, for curiosity), the code looks disgusting. The author (one poor guy) does not have the code in an online VCS and instead dump a source tarball every few months (or years). The upstream vulnerable code was fixed months after news outbreak.

My conclusion is if Apple had a choice it won't end up in iOS at all. Clearly, Apple already paid a lot of maintaining cost in this case (fixing bugs before upstream did), but what you asked for is a whole new level.

There is a well-maintained in-VCS less-disgusting version of Xpdf. It's called Poppler, and Apple chooses to not use it.

Popper is GPL licensed, so Apple cannot use it.

(If you're going to say "but they could use it if they relicensed all of iOS as GPL": don't be daft.)

I guess that is Apple's problem

I think you conflating bugs. Apple doesn't use Xpdf as the basis of the PDF Framework. The NSO bug exploited a bug in the JBIG2 file format. The same implementation of this code was included in both Xpdf and the Apple PDF code. That is why Xpdf needed to also fix the same code.

Of course I mean the fact they use the JBIG2 part of Xpdf. You don't have to use Xpdf for processing PDF in order to use these `class JBIG2*` and you don't even need to patch it.

> any unchecked array or pointer dereference is a potential security risk.

I take exception to this. Of course if I write once-test never, copying from google results and trying to hit jira metrics, then any safety feature in the language will filter out some of the toxic waste code I am producing.

If secure code is designed and engineered, like any other secure technical system would, the language used does not matter so much, but, unsurprisingly, needs to be easy to reason about formally.

That's patently false, or we wouldn't resort to all kinds of tricks to convince the (moderately smart) Go compiler to elide bounds checks (that we know to be unnecessary) from inner loops where they degrade performance significantly.

Reply on news.ycombinator.com