Defense Department Reportedly Relies On Utility Written by Russian Dev (theregister.com) 58
A widely used Node.js utility called fast-glob, relied on by thousands of projectsâ"including over 30 U.S. Department of Defense systems -- is maintained solely by a Russian developer linked to Yandex. While there's no evidence of malicious activity, cybersecurity experts warn that the lack of oversight in such critical open-source projects leaves them vulnerable to potential exploitation by state-backed actors. The Register reports: US cybersecurity firm Hunted Labs reported the revelations on Wednesday. The utility in question is fast-glob, which is used to find files and folders that match specific patterns. Its maintainer goes by the handle "mrmlnc", and the Github profile associated with that handle identifies its owner as a Yandex developer named Denis Malinochkin living in a suburb of Moscow. A website associated with that handle also identifies its owner as the same person, as Hunted Labs pointed out.
Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor. According to Hunted Labs, fast-glob is downloaded more than 79 million times a week and is currently used by more than 5,000 public projects in addition to the DoD systems and Node.js container images that include it. That's not to mention private projects that might use it, meaning that the actual number of at-risk projects could be far greater.
While fast-glob has no known CVEs, the utility has deep access to systems that use it, potentially giving Russia a number of attack vectors to exploit. Fast-glob could attack filesystems directly to expose and steal info, launch a DoS or glob-injection attack, include a kill switch to stop downstream software from functioning properly, or inject additional malware, a list Hunted Labs said is hardly exhaustive. [...] Hunted Labs cofounder Haden Smith told The Register that the ties are cause for concern. "Every piece of code written by Russians isn't automatically suspect, but popular packages with no external oversight are ripe for the taking by state or state-backed actors looking to further their aims," Smith told us in an email. "As a whole, the open source community should be paying more attention to this risk and mitigating it." [...]
Hunted Labs said that the simplest solution for the thousands of projects using fast-glob would be for Malinochkin to add additional maintainers and enhance project oversight, as the only other alternative would be for anyone using it to find a suitable replacement. "Open source software doesn't need a CVE to be dangerous," Hunted Labs said of the matter. "It only needs access, obscurity, and complacency," something we've noted before is an ongoing problem for open source projects. This serves as another powerful reminder that knowing who writes your code is just as critical as understanding what the code does," Hunted Labs concluded.
Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor. According to Hunted Labs, fast-glob is downloaded more than 79 million times a week and is currently used by more than 5,000 public projects in addition to the DoD systems and Node.js container images that include it. That's not to mention private projects that might use it, meaning that the actual number of at-risk projects could be far greater.
While fast-glob has no known CVEs, the utility has deep access to systems that use it, potentially giving Russia a number of attack vectors to exploit. Fast-glob could attack filesystems directly to expose and steal info, launch a DoS or glob-injection attack, include a kill switch to stop downstream software from functioning properly, or inject additional malware, a list Hunted Labs said is hardly exhaustive. [...] Hunted Labs cofounder Haden Smith told The Register that the ties are cause for concern. "Every piece of code written by Russians isn't automatically suspect, but popular packages with no external oversight are ripe for the taking by state or state-backed actors looking to further their aims," Smith told us in an email. "As a whole, the open source community should be paying more attention to this risk and mitigating it." [...]
Hunted Labs said that the simplest solution for the thousands of projects using fast-glob would be for Malinochkin to add additional maintainers and enhance project oversight, as the only other alternative would be for anyone using it to find a suitable replacement. "Open source software doesn't need a CVE to be dangerous," Hunted Labs said of the matter. "It only needs access, obscurity, and complacency," something we've noted before is an ongoing problem for open source projects. This serves as another powerful reminder that knowing who writes your code is just as critical as understanding what the code does," Hunted Labs concluded.
just npm-fund with trumps CC card! (Score:1, Troll)
just npm-fund with trumps CC card!
known Russians covert Russians (Score:4, Informative)
A named person with a verifiable location and employment is less likely to turn malicious than an unnamed (ie, fake named) one. And, devs who intend to plant a time/logic bomb (in a sanely distributed piece of software) or a simple rug pull (in node.js or docker) will use a proxy in a less suspect part of the world.
Heck, I myself offered a bunch of Cuban guys at a conference a VPN they could use for Github (which bans Cuba as an "evil" country); in the end, they went with someone else who has better ping to Cuba. So here goes the idea of banning devs based on their country...
Thus, you'd need to accept named Russians and ban everyone else, from any country other than Russia (as they might use a proxy). Oops...
Re: (Score:2)
There's certainly hostile intent somewhere to be found, you cannot expect to be in a war without the enemy shooting back.
TFA and the likes however, are nothing but porgroms, and they are a way to make more, not less enemies.
Re:known Russians covert Russians (Score:4, Informative)
GitHub don't "ban Cuba" - Cuba is embargoed by US government sanctions.
I don't care what you do, but probably good to at least be aware of the crime you offered to commit for a bunch of guys at a conference.
Re: (Score:2)
Good thing I'm far away from Burgerland, and I have no reason to follow US sanctions.
Paranoid (Score:5, Insightful)
Their issue is really that there is little to no security with these packages. The code is fine now, but just like every other package it could be altered. The only novel thing is that he's Russian.
I somehow doubt he will be interested in adding more developers to make them happy. Someone could fork it, but that doesn't solve any security issues. Just not being Russian doesn't mean anything really.
Re: (Score:3)
Just not being Russian doesn't mean anything really.
By the same token, just being Russian doesn't mean anything really.
Re:Paranoid (Score:4, Insightful)
When your country is invading a neighbour intent on genocide and endlessly threatens Europe and other places then I claim that being Russian means a heck of a lot.
But you are right, in terms of security for this package and all the other thousands of packages in such similar repositories it really does not matter if the author is Russian or some malcontent in a basement in California.
Re: (Score:2)
Only if you assume every citizen of that country wholeheartedly supports the actions of their government.
The only places where that has ever been true have been the "sovereign nations" that amount to a redneck's shack with barbed wire and a load of misspelled signs around it, and even then they probably have moments where they privately wonder if their government might be insane.
Re: Paranoid (Score:2)
7zip is another program that might be at risk.
Think about an offer you can't refuse.
Re:Paranoid (Score:4, Insightful)
Their issue is really that there is little to no security with these packages. The code is fine now, but just like every other package it could be altered.
For anything where security is a consideration, you should always vet included 3rd party code, and maintain an internal "known good" repository to draw from.
Yes, this means you have to update (and re-verify) code in your internal repository regularly to avoid discovered flaws. Modern tools like GIT make this a lot easier than it used to be. It still takes effort and diligence.
It is just part of the cost of security. You can choose not to be secure. Or you can do the work.
Re: (Score:3)
his means you have to update (and re-verify) code in your internal repository regularly
It's the Pentagon, where people still encounter servers with the admin password being something trivial as P@ssw0rd1
Re: (Score:2)
Sounds like things have changed quite a bit since I was stationed there (86-89).
I was a programmer on a main frame with top secret data. The user names we were issued were convoluted enough to make half way decent passwords and the passwords were even better. Certainly nothing so bad as your example.
Memorizing both took me a while and, of course, we couldn't keep a copy of our credentials anywhere but inside the SCIF. And even then they were kept in a sealed (&initialed) envelope that was kept inside
Re: (Score:2)
There definitely was a change then with the flood of client/server systems. When I was still a PC/Server Tech (so some time between 1998 and 2006) the Pentagram audited their servers and found that about ten percent of them had an Administrator password of Password.
Re: (Score:2)
And nearly everyone will choose to not do the work because verifying third party code is a lot of work. This is particularly true with NodeJS where each component gets its own copies of dependencies (instead of having shared dependencies which is usually true in most other environments) and you can have literally thousands of dependencies for a single app.
Re: (Score:2)
>> Someone could fork it, but that doesn't solve any security issues.
Someone could fork it and be less likely to decide (or be forcibly persuaded) to inject some subtle vulnerabilities in the future.
Re: (Score:3)
Yes, unfortunately while the issue is more prominent with NodeJS packages, it is inherently pretty bad all around, including with Python and Go.
For Go there was a recent ssh hacking package that was phoning the results home, so if you tried to test your own infrastructure you would gracefully share the results with hackers. Google does provide a global go mod proxy which should help filter some of the bad packages but I doubt they are capable of validating every single source, especially since most Go modul
Re:Paranoid (Score:4, Insightful)
Articles like this are why The Register is a joke amongst professionals in the field. This is a company using the media to create a PR stunt to drive business, and they are content to be complicit. ALL packages that you don't audit are to be untrusted - it doesn't matter _where_ they come from. Developers in the US and UK can easily be pressed to make code injections under existing national security laws. It doesn't matter _where_ code comes from, it matters if you're stupid enough to run it without auditing it yourself. The argument of Hunterlabs to claim that it matters where your code comes from is jingoistic and incredibly offensive - no one should ever work with these people.
Re: (Score:2)
From The Register article:
"This serves as another powerful reminder that knowing who writes your code is just as critical as understanding what the code does," Hunted Labs concluded.
So you are typing out of your ass.
Re: (Score:3)
But that is nonsense. What the code actually does is what makes it secure or not. Knowing who wrote the code tells you nothing about what the code actually does. It just makes you feel better and lazy. That leads to less rigorous examination of the code you are using, which opens thousands of holes for those with bad intentions.
Re: Paranoid (Score:1)
No ties to any threat actor (Score:2)
Until now. Now the threat actors are aware of this vulnerability, I'm sure they're looking closely at this guy.
Entitled much? (Score:5, Insightful)
So, if I'm understanding this right, the solution is for more people to work for free so I can just blindly grab whatever; not for the people already getting their software for nothing to care even slightly about their dependencies?
Re: (Score:2)
not for the people already getting their software for nothing to care even slightly about their dependencies?
The Defense Department, or any other Org-T that you consider trustworthy, could review and certify open source software that they use and also make their certifications public for others to rely upon.
Instead of specifying a specific version of project X, I could specify the latest version of X that is certified by Org-T, or I could specify the latest version of Org-T's fork of X.
Re: (Score:2)
It's not like it's false that some Yandex software dude will probably cooperate if the FSB tap him on the shoulder and suggest that it's exciting and mandatory; while John Smith, corn-fed American patriot, is at least going to require some sweet-talking; but if you are just blindly grabbing 'package that some dude put on NPM' your problems are far
Nationalism comes to open source (Score:2)
So, how's that whole connect the world via the internet and hope people get over their differences thing been working out?
Mistakes were made (Score:4, Insightful)
I am fully aware of the limitations that made node.js seem like a good idea.
I will get down voted hard, but the problems occured when somebody decided that they wanted to run javascript for a core piece of software. The fact other people piled onto it just compounded the problem.
If you need a thing - you write the software for it. Javascript is probably 30 years old now, but it is still a bad decision.
It is exactly equal to all things container. Sure the idea of a discrete blob that isolates a thing is great...but this is not how anybody is using it. The number of nooblets building environments with hundreds of containers orchestrated to do a certain task is startling. Nooblets that don't have any idea how to actually set up or run a server, multiplying bad practices by the hundreds.
Re: (Score:3, Insightful)
Re:Mistakes were made - Yup! (Score:3)
I wish I had a mod point.
Re: (Score:2)
"If you need a thing - you write the software for it. Javascript is probably 30 years old now, but it is still a bad decision."
I do like that idea. But realistically nobody has the time or money or skill or knowledge to create everything they use. From the boot loader of your machine to the operating system, to the compilers you use and the libraries you depend on. Having everybody recreate the wheel would be a massively inefficient process and likely bankrupt the world's economy if everyone was intent on d
Re: (Score:2, Insightful)
Apparently it's OK to be racist in the US when the target of your hate is Russian, Venezuelan, Iranian, or Chinese. Sometimes North Korean, but the rules keep changing.
Re: (Score:1)
Who modded this race baiting shit up? Shame on you.
He was replied to a software stack rant that had nothing to do with race or nations at all.
Re: (Score:3)
[Citation Needed]
The simplest solution (Score:2)
The actual simplest solution is not for this maintainer to take on additional maintainers and "oversight". The simplest solution is for him to ignore all this and continue maintaining his project however he sees fit. People who release software as open source do not suddenly gain an obligation to mitigate perceived risks or follow corporate policies from their downstream users. This is just another iteration of managers yelling at open source volunteers for not responding to their bug reports in the way
PR stunt by idiots (Score:3)
They "discovered" a fact which was public on github for 5 years. If they were actually interested in cybersecurity they'd be sounding the alarm about the lack of trust of packages in general (obviously projects with tens of maintainers have never had security issues from within.......). This is a PR stunt by a firm that has little expertise and a lot of political pull (management of Mark Esper, among others). All they're doing is using the media to gin up business that they're obviously very bad at.
Cheap PR stunt and rehash. (Score:2)
These are all issues that have been hashed and rehashed for decades. These guys are just ginning up free PR hoping to get some name recognition and business.
8173 Dependents! (Score:2)
A quick look at NPM shows fast-glob has 8173 dependents, and 5 dependencies. A change to micromatch might break 8174 packages.
Or, do it right.
xkcd was wrong! (Score:3, Funny)
So https://xkcd.com/2347/ [xkcd.com] was wrong; it's not a random guy in Nebraska, it's a random guy in a suburb of Moscow.
Re: (Score:1)
Just transfer the work to a Nigerian prince.
In the writeup: (Score:3)
I do love a good disinterested vendor writeup...
JavaScript on the server? (Score:2)
On the positive side: It's open source, it is easy to see what has changed when, and to monitor the repository for malicious changes. So this is a nothing-burger.
On the negative side, WTF is anyone, least of all the DoD, doing with node.js and JavaScript on the server? Seriously?
Absolute joke (Score:3, Insightful)
So a developer writes an open source utility which is apparently very useful judging by the fact that it's used in Node.js and all these projects, and it's completely free. That's great, right? Everybody wins. But, no, he happens to live in a country which US doesn't like very much, and the utility happens to be used by US military, so that means he could do something nefarious. The guy never asked for US military to use his work, it has nothing whatsoever to do with anything military related, being a file search regex as far as I understand. Also this is open source project, so you can actually look at all the source code and see for yourself if there is anything malicious there. Which is exactly what a 'cybersecurity firm' should be doing, instead of doxxing open source developers. Except maybe they don't have anyone who can understand source code.
But the icing on the cake is
Hunted Labs said that the simplest solution for the thousands of projects using fast-glob would be for Malinochkin to add additional maintainers and enhance project oversight
So you write some software, once again, for free, someone with no relationship to you takes your work and uses it, at the risk of sounding repetitive, for free, and then starts demanding that you spend your own money to hire more people (who must presumably all not be Russian) to calm their paranoia that you might do something bad in future. Wow, just wow. Although to be fair this nonsense doesn't come from US DoD but from this complete joke of a 'cybersecurity firm'.
If you start demanding that open source developers pass security clearance (potentially for every military in the world), produce extensive documentation to satisfy whatever compliance standards someone demands etc etc then what's going to happen is people will go 'Fuck this, I have better things to do with my free time'. And then no more open source. And we're back to the old days of everyone doing their own shitty homebrew implementation of every bit of low-level functionality. If DoD wants to write their own implementation of Javascript written entirely by totally security-vetted developers they're welcome to pay contractors however many millions that would require to do exactly that. But it looks like they're actually smart enough to understand that open-source code is pretty secure just by virtue of being used in so many places and being looked at by so many different eyes. It's just this so-called 'cybersecurity firm' trying to get some free publicity by pissing in the well. Ingrates like this just really annoy me.
Re: (Score:2)
Re: (Score:2)
demanding that you spend your own money to hire more people (who must presumably all not be Russian) to calm their paranoia
Well, it says in the summary that "there's no evidence of malicious activity", and Hunted Labs have a long list of things this could potentially be used for.
Since Malinochkin himself doesn't seem to have any interest in exploiting this potential, he will have to hire someone who is more amenable. It is open source, yes, but forking fast-glob is not going to help with injecting bugs.
easiest solution (Score:2)
DevExpress (Score:1)
Um they could fork it (Score:2)
Re: Um they could fork it (Score:1)
I was looking for this comment. I think the same. The repo doesnâ(TM)t even need to be private, so they can obey the licensing terms and contribute their changes back to the community!
Re: Um they could fork it (Score:2)
Re: (Score:2)
Then they could control what's in it.
Yes, but who would use their fork over the original?
Shrug (Score:2)
I would hope the DOD has processes in place to verify the security of all of the software they're using. If not, I think there are some more areas of concern than relying on a Russian's work.
Three choices (Score:2)
One choice (Score:2)
If they don't trust him, they can just pull a local copy and use that.
Or at least pin the last known good version.
They don't need to trust him to use his code.
But they do need him if they want his package to infect other systems.
Blazor Radzen is (Score:2)
common, and has HQ in Bulgaria, a Russian-friendly nation. Should Radzen users be similarly concerned?