7 ms·

You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits

by _wmd 11y ago

You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits were being found at a rate measured in tens per year. Since introduction PDF.js has only had 2 holes that were directly exploitable, neither leading to remote code execution which was the default behaviour for pretty much any bug found in Acrobat. If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. FWIW the entire Firefox UI and every plugin for it is _written_ in Javascript served from local disk. Chrome, Safari and IE aren't far behind

anon1385 11y ago
If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. Just like switching to PDF.js was a decision taken to try and reduce the security attack surface, the decisions to add webgl, webrtc, webfonts, webm, websockets, new css features and so on were all decisions taken in the full knowledge that adding those things would vastly increase the attack surface and inevitably lead to security exploits. These new web features are responsible for a slew of new vulnerabilities and new classes of information leaks.
- deleted 11y ago
  [deleted]
- ronjouch 11y ago
  > (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, > (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. (a) Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). First Rust push in Firefox landed a Rust mp4 parser [1], on 2015-06-17. Others will come; in the meantime, the world keeps turning, and users / web. developers expect these new web features, which Moz devs implement with the infrastructure they have and know. They're not going to cross their hands and declare a moratorium until Rust (or other security-mitigating features/changes) are fully integrated. (b) Not sure what you mean by political reasons and maybe you want to stay stuck in 1992, but I don't, and like many users I do want "webgl, webrtc, webfonts, webm, websockets, new css features and so on" . EDIT I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175322 https://bugzilla.mozilla.org/show_bug.cgi?id=1175322
  - baghira 11y ago
    It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser.
    - ronjouch 11y ago
      > It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). True, that was useless, could have just said "I and many users do want these features" . Thanks, and sorry anon. > the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. That wasn't a links joke, I could have phrased it with your own words "You can install ublock, no(t)script, and disable webgl/webrtc if you want a simple browser letting you read static html documents" , and "But I can't, every website require these features now" would still be an answer. My conclusion isn't that "anyone trying to retain a modicum of control on what its browser does and does not is a luddist" --and I do use some of these extensions too--, it's that the barebones web experience anon wants is broken now (and probably forever), due to: a. Sadly, non-respect of progressive enhancement in cases where it's possible (documents). b. The fact that _some_ parts of the web are increasingly not documents, but whole apps whose progressive-enhancement baseline (running without all the bells and whistles) would do nothing because they depend on these features. > And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser. Yes. Development practices, testing, fuzzing, and safe(r) languages, like Rust.
zzzeek 11y ago
> If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. this is kind of a silly statement. nobody would argue a program shouldn't be able to access local files, in this case, we would presume, PDF content that's been downloaded into a cache. the very simple argument is that the code which deals with opening and reading files from disk should be completely isolated from scripting-language code that runs dynamically in the same object space as the front-end scripting environment. e.g., put the .js in a sandbox by default the way we used to take for granted. I understand that in the Mozilla suite, this barn door was left open years ago and the horses are far and wide by now.
deleted 11y ago
[deleted]
_joev 11y ago
That's not true. There have been PDF.js exploits that lead straight to RCE. This has the additional downside of leading to immediate compromise on every platform. Example (used by Mariusz Mlynski to win Pwn2Own this year): https://www.mozilla.org/en-US/security/advisories/mfsa2015-33/ https://www.mozilla.org/en-US/security/advisories/mfsa2015-3...
- _wmd 11y ago
  Thanks for the link, and bummer, too late to edit my comment.. now I'll be wrong on the Internet for perpetuity :)
  - shimshim 11y ago
    join the club
jacquesm 11y ago
> If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. Thank you for your constructive advice. And I note that so far my stuff written in 'memory unsafe languages' has been in production since '99 or so without a compromise to date over 100's of billions of requests. Maybe it's not just the language. And what business does a browser have with a .pdf file anyway, where does that end? excel sheets? word documents? proprietary format 'x'? Web browsers should stick to web browsing or at least have a mode where they will stick to just web browsing.
- dragonwriter 11y ago
  > And what business does a browser have with a .pdf file anyway, where does that end? excel sheets? word documents? proprietary format 'x'? Web browsers should stick to web browsing or at least have a mode where they will stick to just web browsing. Displaying arbitrary media content is web browsing; the web is an interconnected network of servers providing hypermedia content that is self-describing as to content type so that clients (like browsers) can appropriately choose how to handle content based on its type. Its true that early web browsers only handled HTML, plain text, and a few image formats internally, and relied on external software to handle all other media -- but all of that, including the parts for which they relied on external software -- is part of "web browsing".
  - jacquesm 11y ago
    Sure, and if I install some plug-in to deal with a proprietary format that's my own doing and risk. But by default a browser should stick to a sensible subset otherwise we might as well author our web-pages in .pdf format instead of HTML. Anyway, I've already been called grumpy and being told to sell my laptop and go live in a cave so I'll give HN a miss for the next couple of days or so.
    - tripzilch 11y ago
      :-( but I like your comments! (also let me take the moment to tell you that your recent "Nothing to hide" blog post is great, thanks for writing that)
coffeeaddicted 11y ago
With external pdf-viewers the browser asked each time before downloading and showing a pdf. Now it displays pdf's by default. That's why an exploit could sneak through as advertisment. It couldn't have done that before.

by _wmd 11y ago

anon1385 11y ago

If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. Just like switching to PDF.js was a decision taken to try and reduce the security attack surface, the decisions to add webgl, webrtc, webfonts, webm, websockets, new css features and so on were all decisions taken in the full knowledge that adding those things would vastly increase the attack surface and inevitably lead to security exploits. These new web features are responsible for a slew of new vulnerabilities and new classes of information leaks.

deleted 11y ago
[deleted]
ronjouch 11y ago
> (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, > (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. (a) Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). First Rust push in Firefox landed a Rust mp4 parser [1], on 2015-06-17. Others will come; in the meantime, the world keeps turning, and users / web. developers expect these new web features, which Moz devs implement with the infrastructure they have and know. They're not going to cross their hands and declare a moratorium until Rust (or other security-mitigating features/changes) are fully integrated. (b) Not sure what you mean by political reasons and maybe you want to stay stuck in 1992, but I don't, and like many users I do want "webgl, webrtc, webfonts, webm, websockets, new css features and so on" . EDIT I'd have added "You can install links if you want a simple browser letting you read static html documents", which you would have answered with "But I can't, every website require these features now", to which I'd have answered "a. Yeah, not everyone (that's an understatement) does progressive enhancement, but ultimately b. The times they are a-changing" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175322 https://bugzilla.mozilla.org/show_bug.cgi?id=1175322
- baghira 11y ago
  It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser.
  - ronjouch 11y ago
    > It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). True, that was useless, could have just said "I and many users do want these features" . Thanks, and sorry anon. > the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum of control on what its browser does and does not it a luddist is frankly irritating. That wasn't a links joke, I could have phrased it with your own words "You can install ublock, no(t)script, and disable webgl/webrtc if you want a simple browser letting you read static html documents" , and "But I can't, every website require these features now" would still be an answer. My conclusion isn't that "anyone trying to retain a modicum of control on what its browser does and does not is a luddist" --and I do use some of these extensions too--, it's that the barebones web experience anon wants is broken now (and probably forever), due to: a. Sadly, non-respect of progressive enhancement in cases where it's possible (documents). b. The fact that _some_ parts of the web are increasingly not documents, but whole apps whose progressive-enhancement baseline (running without all the bells and whistles) would do nothing because they depend on these features. > And the whole language debate is completely off point, we have plenty of safe(r) languages for writing stuff, the misguided idea is that the only way to do so is to use javascript and stick the resulting program inside the browser. Yes. Development practices, testing, fuzzing, and safe(r) languages, like Rust.

zzzeek 11y ago

> If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. this is kind of a silly statement. nobody would argue a program shouldn't be able to access local files, in this case, we would presume, PDF content that's been downloaded into a cache. the very simple argument is that the code which deals with opening and reading files from disk should be completely isolated from scripting-language code that runs dynamically in the same object space as the front-end scripting environment. e.g., put the .js in a sandbox by default the way we used to take for granted. I understand that in the Mozilla suite, this barn door was left open years ago and the horses are far and wide by now.

deleted 11y ago

[deleted]

_joev 11y ago

That's not true. There have been PDF.js exploits that lead straight to RCE. This has the additional downside of leading to immediate compromise on every platform. Example (used by Mariusz Mlynski to win Pwn2Own this year): https://www.mozilla.org/en-US/security/advisories/mfsa2015-33/ https://www.mozilla.org/en-US/security/advisories/mfsa2015-3...

_wmd 11y ago
Thanks for the link, and bummer, too late to edit my comment.. now I'll be wrong on the Internet for perpetuity :)
- shimshim 11y ago
  join the club

jacquesm 11y ago

> If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. Thank you for your constructive advice. And I note that so far my stuff written in 'memory unsafe languages' has been in production since '99 or so without a compromise to date over 100's of billions of requests. Maybe it's not just the language. And what business does a browser have with a .pdf file anyway, where does that end? excel sheets? word documents? proprietary format 'x'? Web browsers should stick to web browsing or at least have a mode where they will stick to just web browsing.

dragonwriter 11y ago
> And what business does a browser have with a .pdf file anyway, where does that end? excel sheets? word documents? proprietary format 'x'? Web browsers should stick to web browsing or at least have a mode where they will stick to just web browsing. Displaying arbitrary media content is web browsing; the web is an interconnected network of servers providing hypermedia content that is self-describing as to content type so that clients (like browsers) can appropriately choose how to handle content based on its type. Its true that early web browsers only handled HTML, plain text, and a few image formats internally, and relied on external software to handle all other media -- but all of that, including the parts for which they relied on external software -- is part of "web browsing".
- jacquesm 11y ago
  Sure, and if I install some plug-in to deal with a proprietary format that's my own doing and risk. But by default a browser should stick to a sensible subset otherwise we might as well author our web-pages in .pdf format instead of HTML. Anyway, I've already been called grumpy and being told to sell my laptop and go live in a cave so I'll give HN a miss for the next couple of days or so.
  - tripzilch 11y ago
    :-( but I like your comments! (also let me take the moment to tell you that your recent "Nothing to hide" blog post is great, thanks for writing that)

coffeeaddicted 11y ago

With external pdf-viewers the browser asked each time before downloading and showing a pdf. Now it displays pdf's by default. That's why an exploit could sneak through as advertisment. It couldn't have done that before.