19 ms·

How to build an NPM worm

151 points by 0x0 8y ago

walrus01 8y ago
Question, since I don't use much node.js. Doesn't the repository publish GPG-signing and a checksum hash of every file? The compromised package should have been rejected by the retrieval tool, no?
- pvg 8y ago
  The postmortem is on the HN front page https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes https://eslint.org/blog/2018/07/postmortem-for-malicious-pac... The account of one of the eslint maintainers was compromised.
  - raggi 8y ago
    And this is a critical point. Gpg comes up constantly. It's a waste of everyone's time alive for this use case. If a developer with publish access is compromised, it doesn't help. If the infrastructure is compromised only hash history is required. Hashes are faster to compute in such an emergency, and more available on various mirroring/hosting solutions meaning more likely to have verification sets laying around. A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes. Note: this is based on experience validating all gems after the yaml scare years ago.
    - pvg 8y ago
      I think in this particular case, the user's npm credentials were compromised. In a system where you have separate and independent credentials for generating a valid package and for publishing, this specific attack might have failed. Clicking your heels three times and saying 'GPG', of course, doesn't fix much.
      - raggi 8y ago
        Once you identify a privileged user like this reusing credentials the steps to rooting their box and stealing everything else aren't far away. In this case it wasn't needed, but in any case the threat model and recovery model for packages remains unchanged and my recommendation stands.
    - mirashii 8y ago
      A ledger of hashes doesn't prevent someone from publishing a new version of a package with the stolen credentials. What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure. There may be legitimate reasons to not to use package signing, but this is definitely not one of them.
  - xamuel 8y ago
    >2018-07-12 9:49 UTC: The attacker used the generated authentication token to publish eslint-config-eslint@5.0.2, which contained a malicious postinstall script that attempts to exfiltrate the local machine’s .npmrc authentication token. >2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC. Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...
    - pvg 8y ago
      That's how I read it. Seemed odd they didn't unpublish all updates for the period but then decided it's best to just stop thinking about it.
      - xamuel 8y ago
        For some reason, the situation reminds me of the plot from Dr. Strangelove :P
  - madethemcry 8y ago
    And that's how it was compromised: The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account. I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.
- thosakwe 8y ago
  No, NPM does not have a GPG signing. There was once a PR open, but it was rejected after sitting idle for over a year. Yes, you read that right. https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744
  - PeCaN 8y ago
    Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this. Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.
  - User23 8y ago
    The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware. Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.
  - bodas 8y ago
    How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.
    - pfg 8y ago
      What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.
- _pdp_ 8y ago
  Signing will add another factor indeed. :(
- deleted 8y ago
  [deleted]
  - PeCaN 8y ago
    I assume the parent is being facetious (NPM doesn't support that somewhat useful feature) and node people are a bit butthurt about that currently.
- jlgaddis 8y ago
  As with IOT, apparently the "S" in NPM stands for security.
anonytrary 8y ago
> While the author tried really hard to prevent any errors from being thrown (going as far as wrapping an asynchronous https.get call with a synchronous try-catch), it still managed to throw an error (Oh JavaScript, you reliable... you). ... response.on('data', contents => { eval(contents); }); response.on('error', () => {}); ... --- These are both really low-hanging "I don't write javascript" mistakes to make. Most Node.js devs know that the response is a stream, right? Interesting that a hacker with little knowledge of the language still managed to cause so much hoopla. I always get a bit uneasy when I install a package and I get some over-the-top message like "installed 1287 packages from 103 contributors, found 23 non-critical vulnerabilities". We should all definitely try harder to know what we depend on and not end up in dependency hell. Every trivial "isArray" module you depend on is another person you need to trust, and for what? It takes a second to write a "utilities.js" file and throw in crap like: const isArray = x => x && Array.isArray(x);
- jchw 8y ago
  I never really understood the true appeal of micromodules, but they are especially unappealing in the face of the combinatorial explosion of dependencies and the attack surface they bring with them. I mean if you want a left pad or an is array, is pulling in something established and trusted like lodash really that bad?
  - Kalium 8y ago
    They make a lot of sense to people who like to think functionally. If you view modules as providing functions that you can composite into whatever it is that you need, micromodules are appealing because they offer just want you need and nothing more.
    - krapp 8y ago
      >micromodules are appealing because they offer just want you need and nothing more But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
catchmeifyoucan 8y ago
This was well written. NPM is basically run like Github. I had always thought it was some non-profit org, but that's not the case. It is possible NPM could take the Github route with ssh tokens and only limit NPM publishes to certain authorized computers; a minor step, but you'd have to compromise the computer as well. That could probably be an option in the NPM settings as an extra step.
- deleted 8y ago
  [deleted]
maerF0x0 8y ago
> But honestly, the amount of work we'd all need to put in to truly prevent this from happening again... it's just never going to happen. To me this is the irresponsibility of the NPM maintainers. Require some kind of cryptographic proof you intended to change the code. Signing or TFA or we wont host your w̶o̶r̶m̶ code ...
User23 8y ago
How many times has this happened and not been caught?
- deleted 8y ago
  [deleted]
alangpierce 8y ago
> This means that simply by opening a pull request into the right repo, you can gain authorization to publish packages. Travis CI intentionally avoids this sort of vulnerability by never providing encrypted environment variables when running pull requests from forks: https://docs.travis-ci.com/user/encryption-keys/ https://docs.travis-ci.com/user/encryption-keys/ This is especially necessary because a pull request can make arbitrary code change, like "print the npm access token", which would then run as part of the test suite and show up in the public logs.
alangpierce 8y ago
> Well first we need to know how people would discover it. There's a couple obvious ones... npm emails you by default whenever one of your packages has been published (even by you), so I imagine that would be the most likely way that the problem would be detected in practice.
snek 8y ago
even if you want to use 2FA with npm, they seemingly don't want you to: https://i.imgur.com/2LoEURl.png https://i.imgur.com/2LoEURl.png
- alangpierce 8y ago
  > they seemingly don't want you to What makes you say that? The "not recommended" action in their screenshot is to disable 2FA. (I did find the screen a little confusing when setting up 2FA just now, though; it wasn't clear that it was picking between three different actions.)
  - snek 8y ago
    sorry if i wasn't clear. the fact that npm lets you choose an option with downgraded security (the first option) blows my mind.
juanca 8y ago
Is there any chance to build a sustainable open source project to alleviate some of these problems?
- mike_ivanov 8y ago
  All (well, most) Linux distributions managed to achieve that. So, the chance is about 100%, all it takes is will and skill.
Kiro 8y ago
> This means that simply by opening a pull request into the right repo, you can gain authorization to publish packages. But that is not all what happened here... Or am I reading this wrong?
rmccue 8y ago
Flagged, as URL is now unavailable when linked with the message: This page is unavailable when linked to from news.ycombinator.com. Please find a less toxic place to spend your time. Per https://github.com/jamiebuilds/jamie.build/commit/b66f185df4c2fb25d7da08ba2529eaff5ec16603 https://github.com/jamiebuilds/jamie.build/commit/b66f185df4...
- andrewstuart2 8y ago
  Making a Referrer handler like that is a great way to let me know that you're probably not worth the read anyway, because you're not likely one to listen to anybody else. I've never once found HN a toxic place in the last 4 years. A place to meet people with different opinions and have discussions about those opinions, yeah, but that's beneficial -- literally the opposite of toxic.
  - rusbus 8y ago
    Having had a few posts show up on HN from my site usually because I posted them (although not always), I can say that the comments are frequently nitpicky, unrelated to what you're talking about, and frequently unnecessarily critical. They rarely engage in the substance, and instead engage aggressively in minutiae. Not wanting to have to deal with the HN comments on your work is something I completely understand.
    - andrewstuart2 8y ago
      I'm not saying I don't understand, but I am saying that I've found it more valuable to engage with nitpickers (and learn their perspective while sharing mine) than to continue to do my work in a vacuum free of nitpickers. I've got plenty of nits worth picking. I think most people do.
  - lifthrasiir 8y ago
    My personal opinions: - HN is generally favorable than many other websites, but only because those websites are hopelessly toxic. - Voting system works well for filtering non-informative contents out, but it does prefer some kinds of informative contents than others. - Conflicts in HN are not common, but once started they are hard to control. HN is not a good place for managing conflicts; it's only good for mild discussions and it has no effective measure to stop discussions from becoming conflicts. - Of course there are many different opinions less represented in HN. Some of them can be considered as to an inherent bias of HN.
deleted 8y ago
[deleted]
1uvuutcytj 8y ago
tesr
rubenbe 8y ago
If I click the link, I get the following message: "This page is unavailable when linked to fromn ews.ycombinator.com. Please find a less toxic place to spend your time." Pressing F5 obviously works around this referrer trick, but I find it interesting that someone would (ab)use the HTTP referrer to send a message to visitors from a specific site. This is quite an innocent one, as it is obvious. But what about news/informational sites that subtly modify their message and influce. At least I would not have noticed.
nostalgeek 8y ago
> It bothers me greatly that npm is a private company. It bothers me that npm is closed-source (the registry and server). It bothers me because I can't contribute. I can only inform the community of the problems. NPM the repository is not open source? How does a non open source platform ended up being the default package repository for an open source project is a complete mystery (since NPM client IS bundled with node distribution). People should be allowed to run their own NPM mirror ... for without having to pay for a license. I don't have to pay for packagist or pip server, I can only if I want professional support, so what is this?
- tatersolid 8y ago
  Umm... do you use Github? Docker? Wordpress?
  - nostalgeek 8y ago
    Now please explain me what it has to do with anything I say, since I do not use any of these services.
    - tatersolid 8y ago
      They are all very popular “open source” ecosystem tools beholden to a for-profit corporation. Somebody has to pay the bills.
      - nostalgeek 8y ago
        > They are all very popular “open source” ecosystem tools beholden to a for-profit corporation. NPM server is not open source to begin with. Its client shouldn't be bundled with node, an open source project. I don't use Wordpress but pretty sure I don't have to pay a license to Wordpress to install its CMS on a server. And github server IS NOT open source.
Cofike 8y ago
Cool referrer link check, flagged.
dvfjsdhgfv 8y ago
> My fear is that they are refusing to do something here because they are a startup focused on growth. Their VCs are undoubtably demanding that growth. It sounds like a sad conclusion, but really, what are other reasonable reasons not to fix that glaring security hole that affects millions of direct and indirect users?

151 points by 0x0 8y ago

Question, since I don't use much node.js. Doesn't the repository publish GPG-signing and a checksum hash of every file? The compromised package should have been rejected by the retrieval tool, no?

pvg 8y ago
The postmortem is on the HN front page https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes https://eslint.org/blog/2018/07/postmortem-for-malicious-pac... The account of one of the eslint maintainers was compromised.
- raggi 8y ago
  And this is a critical point. Gpg comes up constantly. It's a waste of everyone's time alive for this use case. If a developer with publish access is compromised, it doesn't help. If the infrastructure is compromised only hash history is required. Hashes are faster to compute in such an emergency, and more available on various mirroring/hosting solutions meaning more likely to have verification sets laying around. A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes. Note: this is based on experience validating all gems after the yaml scare years ago.
  - pvg 8y ago
    I think in this particular case, the user's npm credentials were compromised. In a system where you have separate and independent credentials for generating a valid package and for publishing, this specific attack might have failed. Clicking your heels three times and saying 'GPG', of course, doesn't fix much.
    - raggi 8y ago
      Once you identify a privileged user like this reusing credentials the steps to rooting their box and stealing everything else aren't far away. In this case it wasn't needed, but in any case the threat model and recovery model for packages remains unchanged and my recommendation stands.
  - mirashii 8y ago
    A ledger of hashes doesn't prevent someone from publishing a new version of a package with the stolen credentials. What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure. There may be legitimate reasons to not to use package signing, but this is definitely not one of them.
- xamuel 8y ago
  >2018-07-12 9:49 UTC: The attacker used the generated authentication token to publish eslint-config-eslint@5.0.2, which contained a malicious postinstall script that attempts to exfiltrate the local machine’s .npmrc authentication token. >2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC. Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...
  - pvg 8y ago
    That's how I read it. Seemed odd they didn't unpublish all updates for the period but then decided it's best to just stop thinking about it.
    - xamuel 8y ago
      For some reason, the situation reminds me of the plot from Dr. Strangelove :P
- madethemcry 8y ago
  And that's how it was compromised: The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account. I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.
thosakwe 8y ago
No, NPM does not have a GPG signing. There was once a PR open, but it was rejected after sitting idle for over a year. Yes, you read that right. https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744
- PeCaN 8y ago
  Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this. Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.
- User23 8y ago
  The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware. Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.
- bodas 8y ago
  How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.
  - pfg 8y ago
    What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.
_pdp_ 8y ago
Signing will add another factor indeed. :(
deleted 8y ago
[deleted]
- PeCaN 8y ago
  I assume the parent is being facetious (NPM doesn't support that somewhat useful feature) and node people are a bit butthurt about that currently.
jlgaddis 8y ago
As with IOT, apparently the "S" in NPM stands for security.

anonytrary 8y ago

> While the author tried really hard to prevent any errors from being thrown (going as far as wrapping an asynchronous https.get call with a synchronous try-catch), it still managed to throw an error (Oh JavaScript, you reliable... you). ... response.on('data', contents => { eval(contents); }); response.on('error', () => {}); ... --- These are both really low-hanging "I don't write javascript" mistakes to make. Most Node.js devs know that the response is a stream, right? Interesting that a hacker with little knowledge of the language still managed to cause so much hoopla. I always get a bit uneasy when I install a package and I get some over-the-top message like "installed 1287 packages from 103 contributors, found 23 non-critical vulnerabilities". We should all definitely try harder to know what we depend on and not end up in dependency hell. Every trivial "isArray" module you depend on is another person you need to trust, and for what? It takes a second to write a "utilities.js" file and throw in crap like: const isArray = x => x && Array.isArray(x);

jchw 8y ago
I never really understood the true appeal of micromodules, but they are especially unappealing in the face of the combinatorial explosion of dependencies and the attack surface they bring with them. I mean if you want a left pad or an is array, is pulling in something established and trusted like lodash really that bad?
- Kalium 8y ago
  They make a lot of sense to people who like to think functionally. If you view modules as providing functions that you can composite into whatever it is that you need, micromodules are appealing because they offer just want you need and nothing more.
  - krapp 8y ago
    >micromodules are appealing because they offer just want you need and nothing more But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

catchmeifyoucan 8y ago

This was well written. NPM is basically run like Github. I had always thought it was some non-profit org, but that's not the case. It is possible NPM could take the Github route with ssh tokens and only limit NPM publishes to certain authorized computers; a minor step, but you'd have to compromise the computer as well. That could probably be an option in the NPM settings as an extra step.

deleted 8y ago
[deleted]

maerF0x0 8y ago

> But honestly, the amount of work we'd all need to put in to truly prevent this from happening again... it's just never going to happen. To me this is the irresponsibility of the NPM maintainers. Require some kind of cryptographic proof you intended to change the code. Signing or TFA or we wont host your w̶o̶r̶m̶ code ...

User23 8y ago

How many times has this happened and not been caught?

deleted 8y ago
[deleted]

alangpierce 8y ago

> This means that simply by opening a pull request into the right repo, you can gain authorization to publish packages. Travis CI intentionally avoids this sort of vulnerability by never providing encrypted environment variables when running pull requests from forks: https://docs.travis-ci.com/user/encryption-keys/ https://docs.travis-ci.com/user/encryption-keys/ This is especially necessary because a pull request can make arbitrary code change, like "print the npm access token", which would then run as part of the test suite and show up in the public logs.

alangpierce 8y ago

> Well first we need to know how people would discover it. There's a couple obvious ones... npm emails you by default whenever one of your packages has been published (even by you), so I imagine that would be the most likely way that the problem would be detected in practice.

snek 8y ago

even if you want to use 2FA with npm, they seemingly don't want you to: https://i.imgur.com/2LoEURl.png https://i.imgur.com/2LoEURl.png

alangpierce 8y ago
> they seemingly don't want you to What makes you say that? The "not recommended" action in their screenshot is to disable 2FA. (I did find the screen a little confusing when setting up 2FA just now, though; it wasn't clear that it was picking between three different actions.)
- snek 8y ago
  sorry if i wasn't clear. the fact that npm lets you choose an option with downgraded security (the first option) blows my mind.

juanca 8y ago

Is there any chance to build a sustainable open source project to alleviate some of these problems?

mike_ivanov 8y ago
All (well, most) Linux distributions managed to achieve that. So, the chance is about 100%, all it takes is will and skill.

Kiro 8y ago

> This means that simply by opening a pull request into the right repo, you can gain authorization to publish packages. But that is not all what happened here... Or am I reading this wrong?

rmccue 8y ago

Flagged, as URL is now unavailable when linked with the message: This page is unavailable when linked to from news.ycombinator.com. Please find a less toxic place to spend your time. Per https://github.com/jamiebuilds/jamie.build/commit/b66f185df4c2fb25d7da08ba2529eaff5ec16603 https://github.com/jamiebuilds/jamie.build/commit/b66f185df4...

andrewstuart2 8y ago
Making a Referrer handler like that is a great way to let me know that you're probably not worth the read anyway, because you're not likely one to listen to anybody else. I've never once found HN a toxic place in the last 4 years. A place to meet people with different opinions and have discussions about those opinions, yeah, but that's beneficial -- literally the opposite of toxic.
- rusbus 8y ago
  Having had a few posts show up on HN from my site usually because I posted them (although not always), I can say that the comments are frequently nitpicky, unrelated to what you're talking about, and frequently unnecessarily critical. They rarely engage in the substance, and instead engage aggressively in minutiae. Not wanting to have to deal with the HN comments on your work is something I completely understand.
  - andrewstuart2 8y ago
    I'm not saying I don't understand, but I am saying that I've found it more valuable to engage with nitpickers (and learn their perspective while sharing mine) than to continue to do my work in a vacuum free of nitpickers. I've got plenty of nits worth picking. I think most people do.
- lifthrasiir 8y ago
  My personal opinions: - HN is generally favorable than many other websites, but only because those websites are hopelessly toxic. - Voting system works well for filtering non-informative contents out, but it does prefer some kinds of informative contents than others. - Conflicts in HN are not common, but once started they are hard to control. HN is not a good place for managing conflicts; it's only good for mild discussions and it has no effective measure to stop discussions from becoming conflicts. - Of course there are many different opinions less represented in HN. Some of them can be considered as to an inherent bias of HN.

deleted 8y ago

[deleted]

1uvuutcytj 8y ago

tesr

rubenbe 8y ago

If I click the link, I get the following message: "This page is unavailable when linked to fromn ews.ycombinator.com. Please find a less toxic place to spend your time." Pressing F5 obviously works around this referrer trick, but I find it interesting that someone would (ab)use the HTTP referrer to send a message to visitors from a specific site. This is quite an innocent one, as it is obvious. But what about news/informational sites that subtly modify their message and influce. At least I would not have noticed.

nostalgeek 8y ago

> It bothers me greatly that npm is a private company. It bothers me that npm is closed-source (the registry and server). It bothers me because I can't contribute. I can only inform the community of the problems. NPM the repository is not open source? How does a non open source platform ended up being the default package repository for an open source project is a complete mystery (since NPM client IS bundled with node distribution). People should be allowed to run their own NPM mirror ... for without having to pay for a license. I don't have to pay for packagist or pip server, I can only if I want professional support, so what is this?

tatersolid 8y ago
Umm... do you use Github? Docker? Wordpress?
- nostalgeek 8y ago
  Now please explain me what it has to do with anything I say, since I do not use any of these services.
  - tatersolid 8y ago
    They are all very popular “open source” ecosystem tools beholden to a for-profit corporation. Somebody has to pay the bills.
    - nostalgeek 8y ago
      > They are all very popular “open source” ecosystem tools beholden to a for-profit corporation. NPM server is not open source to begin with. Its client shouldn't be bundled with node, an open source project. I don't use Wordpress but pretty sure I don't have to pay a license to Wordpress to install its CMS on a server. And github server IS NOT open source.

Cofike 8y ago

Cool referrer link check, flagged.

dvfjsdhgfv 8y ago

> My fear is that they are refusing to do something here because they are a startup focused on growth. Their VCs are undoubtably demanding that growth. It sounds like a sad conclusion, but really, what are other reasonable reasons not to fix that glaring security hole that affects millions of direct and indirect users?