Long-time Slashdot reader theodp writes: In On the Weaponisation of Open Source, software engineering consultant Gerald Benischke examines how the Russian invasion of Ukraine has spilled over into areas of software development, with some unintended consequences. In particular, Benischke looks at the decision by MongoDB to cut off services in Russia, the destructive change in a node library that deleted files on Russian IPs, and even a change in the code/licence in a community terraform module to assert that Putin is a 'dickhead.'

Benischke concludes, "My problem is that this weaponisation is killing off trust. I think the temptation of using open source projects as weapons against Russia should be resisted because it sets a dangerous precedent and may ultimately set back the open source movement and push organisations back into seeking refuge in commercial software with all its opaqueness and obscurity. It's not about sitting on the fence or taking sides in a war. It's about what open source has achieved over the last 30 years and I think that's now at risk of become collateral damage."

Meanwhile, the war is also being fought on the Cloud front, with Microsoft halting all new sales in Russia. In fact, all of the major U.S. cloud providers have stepped back from doing business in Russia. "You basically have Russia becoming a commercial pariah," explained economist Mary Lovely. "Pretty much no company, no multinational, wants to be caught on the wrong side of U.S. and Western sanctions."

The developer behind the popular npm package 'node-ipc' released sabotaged versions of the library in protest of the ongoing Russo-Ukrainian War, BleepingComputer reports. From the article: Newer versions of the 'node-ipc' package began deleting all data and overwriting all files on developer's machines, in addition to creating new text files with "peace" messages. With over a million weekly downloads, 'node-ipc' is a prominent package used by major libraries like Vue.js CLI.

Select versions (10.1.1 and 10.1.2) of the massively popular 'node-ipc' package were caught containing malicious code that would overwrite or delete arbitrary files on a system for users based in Russia and Belarus. These versions are tracked under CVE-2022-23812. On March 8th, developer Brandon Nozaki Miller, aka RIAEvangelist released open source software packages called peacenotwar and oneday-test on both npm and GitHub. The packages appear to have been originally created by the developer as a means of peaceful protest, as they mainly add a "message of peace" on the Desktop of any user installing the packages. "This code serves as a non-destructive example of why controlling your node modules is important," explains RIAEvangelist.

"Much of the most widely used free and open source software is developed by only a handful of contributors," warns the Linux Foundation, in the executive summary for its massive new census of free and open source software application libraries. It was prepared in conjunction with Harvard's Laboratory for Innovation Science — and that's just one of its five high-level findings.

The census also notes "the increasing importance of individual developer account security," but also the persistence of legacy software, the need for a standardized naming schema for software components, and "complexities" around package versions. But there's also just a lot of data about package popularity, writes SD Times: The report, Census II, is a follow-up to Census I, which was conducted in 2015 to identify the packages in Debian Linux that were most critical to the operation and security of the kernel. According to the Linux Foundation, Census II allows for a more "complete picture of free and open source (FOSS) adoption."

"Understanding what FOSS packages are the most critical to society allows us to proactively support projects that warrant operations and security support," said Brian Behlendorf, executive director at Linux Foundation's Open Source Security Foundation (OpenSSF).
The census "aggregates data from over half a million observations of FOSS libraries used in production applications at thousands of companies," according to its executive summary. It argues that preserving FOSS will require this kind of data-sharing (about where and how FOSS packages are being used ) as well as coordination — including standardizing terminology — and of course, investment.

"The motivation behind publishing these findings is to not only inform, but also to inspire action by developers to improve their security practices and by end users to support the FOSS ecosystem and developers who need assistance." (It suggests companies companies could provide not just financial support but also the technical talent and their time.) The results take the form of eight Top 500 lists — four that include version numbers in the analysis and four that are version agnostic. Further, as mentioned above, we present npm and non-npm packages in separate lists... Although these lists provide valuable, important insights into the most widely used FOSS projects, it is important to also consider the level of security related to these projects. Therefore, in each list, we also include the "Tiered %" measure from the OpenSSF Best Practices Badging Program....

From Mike Melanson's "This Week in Programming" column: The 20th anniversary of .NET is upon us this week and with it, Microsoft is pulling out all the stops in celebration of what it says is "the most loved framework by developers for three years in a row now — 2019, 2020, 2021, according to Stack Overflow's developer survey."

First launched in 2002, .NET is, in some ways, something that Microsoft can roll out as evidence of its changed ways over the years. It went from a company embroiled in a monopoly case just a year before this release, to one that later decided to turn around, mend its former ways, and open source .NET Core. "When Microsoft made another major transformation, this time towards open source, .NET was also at the forefront," Microsoft writes in this week's celebratory blog post. "By 2012, we had fully open-sourced the ASP.NET MVC web framework and were accepting contributions. It was one of Microsoft's first major open-source projects at the time. In 2014, we started to build a cross-platform and open-source .NET on GitHub and were floored at the incredible support and contributions from the open-source community...."

Certainly, in comparison to the Microsoft we once knew, there has been a massive shift in its approach to open source software and openness in general. Indeed, these days, Microsoft is also synonymous with another giant in the world of open source, its now-subsidiary GitHub — as well as the npm Registry and countless other projects. Microsoft has transformed from a company that was once led by a man who said that "Linux is a cancer" to one that has more recently welcomed Linux to the Windows desktop, among numerous other open source endeavors.
The column ends by remembering what it calls "Microsoft 'hot reload' drama" last year — Microsoft's removal of the feature from the .NET SDK repo (and its subsequent return, with an apology). "All that's to say, perhaps all's well that ends well, and we should indeed celebrate 20 years of success with a now open source framework. In the same breath, vigilance may be necessary should we want to celebrate another such anniversary in the future."

An academic research project found that thousands of JavaScript developers are using an email address with an expired domain for their npm accounts, leaving their projects exposed to easy hijacks. From a report: The study, performed last year by researchers from Microsoft and North Caroline State University, analyzed the metadata of 1,630,101 libraries uploaded on Node Package Manager (npm), the de-facto repository for JavaScript libraries and the largest package repository on the internet. Researchers said they found that 2,818 project maintainers were still using an email address for their accounts that had an expired domain, some of which they found on sale on sites like GoDaddy. The team argued that attackers could buy these domains, re-register the maintainer's address on their own email servers, and then reset the maintainer's account password and take over his npm packages.

The administrators of the Node Package Manager (npm), the largest package repository of the JavaScript ecosystem, said they enrolled the maintainers of the top 100 most popular libraries (based on the number of dependencies) into their mandatory two-factor authentication (2FA) procedure. From a report: npm, which is owned by GitHub, enforced this new security requirement starting yesterday, February 1, 2022. "Maintainers who do not currently have 2FA enabled will have their web sessions revoked and will need to set up 2FA before they can take specific actions with their accounts, such as changing their email address or adding new maintainers to projects," the GitHub security team said in a blog post. The move represents the second phase of a major push from the npm team to secure developer accounts, which have been getting hijacked in recent years and used to push malware inside legitimate JavaScript libraries. In many cases, the accounts are hacked because project maintainers use simple-to-guess passwords or reused passwords that were previously leaked via breaches at other companies. The first phase of this process took place between December 7, 2021, and January 4, 2022, when the npm team rolled out a new feature called "enhanced login verification" for all npm package maintainers.

Remember that developer who intentionally corrupted his two libraries which collectively had over 20 million weekly downloads and thousands of dependent projects? In the immediate aftermath he'd complained on Twitter that NPM "has reverted to a previous version of the faker.js package and Github has suspended my access to all public and private projects. I have 100s of projects. #AaronSwartz."

That was January 6th, and within about a week GitHub had restored his access, while one of his two libraries (faker-js) was forked by its community to create a community-driven project. But Thursday the developer announced on his Twitter account: What's up @Github? Ten days since you removed my ability to publish to NPM and fix the Infinity Zalgo bug in colors.js

Never responded to my support emails.

I have 100s of packages I need to maintain.

Everyone makes programming mistakes from time to time. Nobody is perfect.
It hasn't been confirmed that NPM has actually blocked his ability to publish — but the tweet already appears to be attracting reactions from other developers on social media.

Owen Williams, writing for TechCrunch: [...] As a result, it shouldn't be a surprise that some open source developers are beginning to realize they wield outsized power, despite the lack of compensation they receive for their work, because their projects are used by some of the largest, most profitable companies in the world. In early January, for example, Marak Squires, the developer of two popular NPM packages, 'colors' and 'faker,' intentionally introduced changes to their code that broke their functionality for anyone using them, outputting "LIBERTY LIBERTY LIBERTY" followed by gibberish and an infinite loop when used. While Squires didn't comment on the reason for making the changes, he had previously said on GitHub that "I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work." Squires' changes broke other popular projects, including Amazon's Cloud Development Kit, as his libraries were installed almost 20 million times per week on npm, with thousands of projects directly depending on them. Within a few hours, NPM had rolled back the rogue release and GitHub suspended the developer's account in response.

While NPM's response was to be expected after previous incidents in which malicious code was added to libraries and was ultimately rolled back to limit damage, GitHub's was a new one: the code hosting platform took down Squires' entire account, even though he was the owner of the code and was his rights to change it as he pleased. This isn't the first time a developer has pulled their code in protest, either. The developer of 'left-pad' pulled his code from NPM in 2016, breaking tens of thousands of websites that depended on it following a fight with the Kik messenger over the naming of another open source project he owned. What's astonishing is that despite the occasional high-profile libraries protesting the way the industry works, these types of incidents aren't all that common: open source developers continue to work for free, maintaining their projects as best they can, even though multi-million dollar products being created off of the back of their work.

Last weekend a developer intentionally corrupted two of his libraries which collectively had more than 20 million weekly downloads and thousands of dependent projects.

Eight days later, one of those libraries has become a community controlled project.

Some highlights from the announcement at fakerjs.dev: We're a group of engineers who were using Faker in prod when the main package was deleted. We have eight maintainers currently....

What has the team done so far?

1. Created a GitHub org [repository] for the new Faker package under @faker-js/faker.
2. Put together a team of eight maintainers.
3. Released all previous versions of Faker at @faker-js/faker on npm.
4. Released the Version 6 Alpha
5. Almost completed migrating to TypeScript so that DefinitelyTyped no longer needs to maintain its external @types/faker package.
6. Created a public Twitter account for communicating with the community.
7. Released the first official Faker documentation website....

Faker has never had an official docs website and the awesome Jeff Beltran has been maintaining a project called "Un-Official faker.js Documentation" for the last 3 years.

He gave us permission to re-use his work to create fakerjs.dev

8. Cleaned up tooling like Prettier, CI, Netlify Deploy Previews, and GitHub Actions.
9. Done a TON of issue triage and many, many PR reviews.
10. We've gotten in contact with the Open Collective and discussed a transition plan for the project.

We fully intend to extend Faker, continuously develop it, and make it even better.

As such, we will work on a roadmap after we release 6.x and merge all of the TypeScript Pull Requests in the next week....

We're now turning Faker into a community-controlled project currently maintained by eight engineers from various backgrounds and companies....

We're excited to give new life to this idea and project.

This project can have a fresh start and it will become even cooler.

We felt we needed to do a public announcement because of all of the attention the project received in the media and from the community.

We believe that we have acted in the way that is best for the community.
According to the announcement, they've now also forked the funding so the project's original sponsors can continue to support the community-driven development in the future, while the original developers Marak and Brian "were able to retain the $11,652.69 USD previously donated to the project."

Friday the official Twitter account for the new community project announced "It's been a week. We've merged all of the active forks. Currently at 1532 stars. Looks like everything is settling." [It's now up to over 1,800 stars.]

One of the new maintainers has posted on Twitter, "I'm just grateful to the faker community that willed itself into existence and stepped up."

What happened after a developer intentionally corrupted two of their libraries which collectively had more than 20 million weekly downloads and thousands of dependent projects?

Mike Melanson's "This Week in Programming" column reports: In response to the corrupted libraries, Microsoft quickly suspended his GitHub access and reverted the projects on npm.... While this might seem like an open and shut case to some — the developer committed malicious code and GitHub and npm did what it had to do to protect its users — a debate broke out around a developer's rights to do what they wish with their code, no matter how many projects and dependencies it may have.

"GitHub suspending someone's account for modifying their own code in a project they own however they want spooks me a lot more than NPM reverting a package," [tweeted one company's Director of Engineering & Technology]. "I kind of love what Marak did to make a point and protest to be honest."

An article on iProgrammer further outlines the dilemma present in what might otherwise seem like a clear-cut case.... "Yes, it is open source in that you can fork it and can contribute to it but does this mean that GitHub is justified in denying you the right to change or even destroy your own code?"

As of last night, however, it would appear that the entire affair is merely one for intellectual debate, as GitHub has indeed lived up to what some might view as its end of the bargain: the developer's account is active, he has been allowed to remove his faker.js library on GitHub (depended upon as it might be), and has since offered an update that he does "not have Donkey Brains".

"Users of popular open-source libraries 'colors' and 'faker' were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.." reports BleepingComputer.

"The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on 'colors and 'faker'." The colors library receives over 20 million weekly downloads on npm alone, and has almost 19,000 projects depending on it. Whereas, faker receives over 2.8 million weekly downloads on npm, and has over 2,500 dependents....

Yesterday, users of popular open-source projects, such as Amazon's Cloud Development Kit were left stunned on seeing their applications print gibberish messages on their console. These messages included the text 'LIBERTY LIBERTY LIBERTY' followed by a sequence of non-ASCII characters... The developer, named Marak Squires added a "new American flag module" to colors.js library yesterday in version v1.4.44-liberty-2 that he then pushed to GitHub and npm. The infinite loop introduced in the code will keep running indefinitely; printing the gibberish non-ASCII character sequence endlessly on the console for any applications that use 'colors.' Likewise, a sabotaged version '6.6.6' of faker was published to GitHub and npm....

The reason behind this mischief on the developer's part appears to be retaliation — against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community. In November 2020, Marak had warned that he will no longer be supporting the big corporations with his "free work" and that commercial entities should consider either forking the projects or compensating the dev with a yearly "six figure" salary....

Some dubbed this an instance of "yet another OSS developer going rogue," whereas InfoSec expert VessOnSecurity called the action "irresponsible," stating: "If you have problems with business using your free code for free, don't publish free code. By sabotaging your own widely used stuff, you hurt not only big business but anyone using it. This trains people not to update, 'coz stuff might break."

GitHub has reportedly suspended the developer's account. And, that too, has caused mixed reactions... "Removing your own code from [GitHub] is a violation of their Terms of Service? WTF? This is a kidnapping. We need to start decentralizing the hosting of free software source code," responded software engineer Sergio Gómez.
"While it looks like color.js has been updated to a working version, faker.js still appears to be affected, but the issue can be worked around by downgrading to a previous version (5.5.3)," reports the Verge: Even more curiously, the faker.js Readme file has also been changed to "What really happened with Aaron Swartz...?"

Squires' bold move draws attention to the moral — and financial — dilemma of open-source development, which was likely the goal of his actions.

In 2020 Microsoft's GitHub acquired NPM (makers of the default package manager for Node.js). The company's web page boasts that npm "is a critical part of the JavaScript community and helps support one of the largest developer ecosystems in the world."

But now BleepingComputer reports on two security flaws found (and remediated) in its software registry. Names of private npm packages on npmjs.com's 'replica' server (consumed by third-party services) were leaked — but in addition, a second flaw could've allowed attackers "to publish new versions of any existing npm package that they do not own or have rights to, due to improper authorization checks."

In a blog post this week GitHub's chief security officer explained the details: During maintenance on the database that powers the public npm replica at replicate.npmjs.com, records were created that could expose the names of private packages. This briefly allowed consumers of replicate.npmjs.com to potentially identify the names of private packages due to records published in the public changes feed. No other information, including the content of these private packages, was accessible at any time. Package names in the format of @owner/package for private packages created prior to October 20 were exposed between October 21 13:12:10Z UTC and October 29 15:51:00Z UTC. Upon discovery of the issue, we immediately began work on implementing a fix and determining the scope of the exposure. On October 29, all records containing private package names were removed from the replication database. While these records were removed from the replicate.npmjs.com service on this date, the data on this service is consumed by third-parties who may have replicated the data elsewhere. To prevent this issue from occuring again, we have made changes to how we provision this public replication database to ensure records containing private package names are not generated during this process.

Second, on November 2 we received a report to our security bug bounty program of a vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. We quickly validated the report, began our incident response processes, and patched the vulnerability within six hours of receiving the report.

We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file. This discrepancy provided an avenue by which requests to publish new versions of a package would be authorized for one package but would actually be performed for a different, and potentially unauthorized, package. We mitigated this issue by ensuring consistency across both the publishing service and authorization service to ensure that the same package is being used for both authorization and publishing.

This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously. However, we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020.
BleepingComputer adds: Both announcements come not too long after popular npm libraries, 'ua-parser-js,' 'coa,' and 'rc' were hijacked in a series of attacks aimed at infecting open source software consumers with trojans and crypto-miners. These attacks were attributed to the compromise of npm accounts [1, 2] belonging to the maintainers behind these libraries.

None of the maintainers of these popular libraries had two-factor authentication (2FA) enabled on their accounts, according to GitHub. Attackers who can manage to hijack npm accounts of maintainers can trivially publish new versions of these legitimate packages, after contaminating them with malware. As such, to minimize the possibility of such compromises from recurring in near future, GitHub will start requiring npm maintainers to enable 2FA, sometime in the first quarter of 2022.

Microsoft said Wednesday that Nat Friedman, CEO of the company's GitHub subsidiary that provides software for storing source code, is stepping down. Thomas Dohmke, GitHub's product chief will replace him. CNBC reports: "As Chief Product Officer, I'm proud of the work our teams have done to bring new capabilities to GitHub Codespaces, Issues, Copilot, and many of the 20,000 improvements that we shipped last year," Dohmke wrote in a blog post. "Together, we've built a roadmap that will transform the developer experience for open source maintainers and enterprises using GitHub for years to come." Dohmke takes over for Friedman on Nov. 15.

Friedman is "very excited to go back to my startup roots to support and invest in the builders who are creating the world of tomorrow," he wrote in a tweet. He will be an advisor to both GitHub and Microsoft, Scott Guthrie, executive vice president for Microsoft's cloud and artificial intelligence group, wrote in an email to employees. Dohmke first registered as a GitHub user in 2009, not long after its founding in 2008. He was co-founder and CEO of app-testing software start-up HockeyApp, which Microsoft acquired in 2014. He moved to GitHub at the time Microsoft closed the GitHub acquisition in 2018. Dohmke "led the GitHub acquisition process on the Microsoft engineering side from the deal signing to the successful acquisition close," Guthrie wrote in his email. Dohmke later led the acquisitions of Npm, a code-distribution start-up, and Semmle, a start-up whose software helps organizations analyze code to uncover security issues, Guthrie wrote.

Threatpost reports on "another vast software supply-chain attack" that was "found lurking in the npm open-source code repository...a credentials-stealing code bomb" that used the password-recovery tools in Google's Chrome web browser. Researchers caught the malware filching credentials from Chrome on Windows systems. The password-stealer is multifunctional: It also listens for incoming commands from the attacker's command-and-control (C2) server and can upload files, record from a victim's screen and camera, and execute shell commands...

ReversingLabs researchers, who published their findings in a Wednesday post, said that during an analysis of the code repository, they found an interesting embedded Windows executable file: a credential-stealing threat. Labeled "Win32.Infostealer.Heuristics", it showed up in two packages: nodejs_net_server and temptesttempfile. At least for now, the first, main threat is nodejs_net_server. Some details:

nodejs_net_server: A package with 12 published versions and a total of more than 1,300 downloads since it was first published in February 2019...finally upgrading it last December with a script to download the password-stealer, which the developer hosts on a personal website. It was subsequently tweaked to run TeamViewer.exe instead, "probably because the author didn't want to have such an obvious connection between the malware and their website," researchers theorized...

ReversingLabs contacted the npm security team on July 2 to give them a heads-up about the nodejs_net_server and tempdownloadtempfile packages and circled back once again last week, on Thursday, since the team still hadn't removed the packages from the repository. When Threatpost reached out to npm Inc., which maintains the repository, a GitHub spokesperson sent this statement: "Both packages were removed following our investigation...."

From today's edition of Mike Melanson's "This Week in Programming" column: If you've been using open source software for any amount of time, then you're well aware of the tangled web of dependencies often involved in such projects. If not, there's any number of tools out there that explore just how interconnected everything is, and this week Google has jumped into the game with its own offering — an exploratory visualization site called Open Source Insights that gives users an interactive view of dependencies of open source projects.

Now, Google isn't the first to get into the game of trying to uncover and perhaps untangle the dizzying dependency graph of the open source world, but the company argues that it is more so trying to lay everything out in a way that developers can see, visually, just how, well, hopelessly screwed they really are.

"There are tools to help, of course: vulnerability scanners and dependency audits that can help identify when a package is exposed to a vulnerability. But it can still be difficult to visualize the big picture, to understand what you depend on, and what that implies," they write.

The Open Source Insights tool — currently "experimental" — gives users either a table or graphical visualization of how a project is composed, allowing them to explore the dependency graph and examine how using different versions of certain projects might actually affect that dependency graph. One of the benefits, Google notes, is that it allows users to see all this information "without asking you to install the package first. You can see instantly what installing a package — or an updated version — might mean for your project, how popular it is, find links to source code and other information, and then decide whether it should be installed."

Currently, the tool supports npm, Maven, Go modules, and Cargo, with more packaging systems on the way soon...

"The official Python software package repository, PyPI, is getting flooded with spam packages..." Bleeping Computer reported Thursday.

"Each of these packages is posted by a unique pseudonymous maintainer account, making it challenging for PyPI to remove the packages and spam accounts all at once..." PyPI is being flooded with spam packages named after popular movies in a style commonly associated with torrent or "warez" sites that provide pirated downloads: watch-(movie-name)-2021-full-online-movie-free-hd-... Although some of these packages are a few weeks old, BleepingComputer observed that spammers are continuing to add newer packages to PyPI... The web page for these bogus packages contain spam keywords and links to movie streaming sites, albeit of questionable legitimacy and legality...

February of this year, PyPI had been flooded with bogus "Discord", "Google", and "Roblox" keygens in a massive spam attack, as reported by ZDNet. At the time, Ewa Jodlowska, Executive Director of the Python Software Foundation had told ZDNet that the PyPI admins were working on addressing the spam attack, however, by the nature of pypi.org, anyone could publish to the repository, and such occurrences were common.

Other than containing spam keywords and links to quasi-video streaming sites, these packages contain files with functional code and author information lifted from legitimate PyPI packages... As previously reported by BleepingComputer, malicious actors have combined code from legitimate packages with otherwise bogus or malicious packages to mask their footsteps, and make the detection of these packages a tad more challenging...

In recent months, the attacks on open-source ecosystems like npm, RubyGems, and PyPI have escalated. Threat actors have been caught flooding software repositories with malware, malicious dependency confusion copycats, or simply vigilante packages to spread their message. As such, securing these repositories has turned into a whack-a-mole race between threat actors and repository maintainers.

chicksdaddy shares a report from The Security Ledger: Independent security researchers analyzing the widely used open source component netmask have discovered security vulnerabilities that could leave more than a quarter million open source applications vulnerable to attack, according to a report released Monday, The Security Ledger reports. According to a report by the site Sick Codes, the flaws open applications that rely on netmask to a wide range of malicious attacks including Server Side Request Forgeries (SSRF) and Remote- and Local File Includes (RFI, LFI) that could enable attackers to ferry malicious code into a protected network, or siphon sensitive data out of one. Even worse, the flaws appear to stretch far beyond a single open source module, affecting a wide range of open source development languages, researchers say.

Netmask is a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined "block." According to the researcher using the handle "Sick Codes," the researchers discovered that netmask had a big blind spot. Specifically: it evaluates certain IP addresses incorrectly: improperly validating so-called "octal strings" rendering IPv4 addresses that contain certain octal strings as integers. For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string "0177" translates to the integer "127." However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer.

The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address. Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks. But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses were never standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.

Jake Edge, writing at LWN: The problems with "vendoring" in packages -- bundling dependencies rather than getting them from other packages -- seems to crop up frequently these days. We looked at Debian's concerns about packaging Kubernetes and its myriad of Go dependencies back in October. A more recent discussion in that distribution's community looks at another famously dependency-heavy ecosystem: JavaScript libraries from the npm repository. Even C-based ecosystems are not immune to the problem, as we saw with iproute2 and libbpf back in November; the discussion of vendoring seems likely to recur over the coming years. Many application projects, particularly those written in languages like JavaScript, PHP, and Go, tend to have a rather large pile of dependencies. These projects typically simply download specific versions of the needed dependencies at build time. This works well for fast-moving projects using collections of fast-moving libraries and frameworks, but it works rather less well for traditional Linux distributions. So distribution projects have been trying to figure out how best to incorporate these types of applications.

This time around, Raphael Hertzog raised the issue with regard to the Greenbone Security Assistant (gsa), which provides a web front-end to the OpenVAS vulnerability scanner (which is now known as Greenbone Vulnerability Management or gvm). "the version currently in Debian no longer works with the latest gvm so we have to update it to the latest upstream release... but the latest upstream release has significant changes, in particular it now relies on yarn or npm from the node ecosystem to download all the node modules that it needs (and there are many of them, and there's no way that we will package them individually). The Debian policy forbids download during the build so we can't run the upstream build system as is."

Hertzog suggested three possible solutions: collecting all of the dependencies into the Debian source package (though there would be problems creating the copyright file), moving the package to the contrib repository and adding a post-install step to download the dependencies, or removing gsa from Debian entirely. He is working on updating gsa as part of his work on Kali Linux, which is a Debian derivative that is focused on penetration testing and security auditing. Kali Linux does not have the same restrictions on downloading during builds that Debian has, so the Kali gsa package can simply use the upstream build process. He would prefer to keep gsa in Debian, "but there's only so much busy-work that I'm willing to do to achieve this goal". He wondered if it made more sense for Debian to consider relaxing its requirements. But Jonas Smedegaard offered another possible approach: analyzing what packages are needed by gsa and then either using existing Debian packages for those dependencies or creating new ones for those that are not available. Hertzog was convinced that wouldn't be done, but Smedegaard said that the JavaScript team is already working on that process for multiple projects.

The security team behind the "npm" repository for JavaScript libraries removed two npm packages this Monday for containing malicious code that installed a remote access trojan (RAT) on the computers of developers working on JavaScript projects. From a report: The name of the two packages was jdb.js and db-json.js., and both were created by the same author and described themselves as tools to help developers work with JSON files typically generated by database applications. Both packages were uploaded on the npm package registry last week and were downloaded more than 100 times before their malicious behavior was detected by Sonatype, a company that scans package repositories on a regular basis. According to Sonatype's Ax Sharma, the two packages contained a malicious script that executed after web developers imported and installed any of the two malicious libraries. The post-install script performed basic reconnaissance of the infected host and then attempted to download and run a file named patch.exe that later installed njRAT, also known as Bladabindi, a very popular remote access trojan that has been used in espionage and data theft operations since 2015.

"Three JavaScript packages have been removed from the npm portal on Thursday for containing malicious code," reports ZDNet.

"According to advisories from the npm security team, the three JavaScript libraries opened shells on the computers of developers who imported the packages into their projects." The shells, a technical term used by cyber-security researchers, allowed threat actors to connect remotely to the infected computer and execute malicious operations. The npm security team said the shells could work on both Windows and *nix operating systems, such as Linux, FreeBSD, OpenBSD, and others.

All three packages were uploaded on the npm portal in May (first) and September 2018 (last two). Each package had hundreds of downloads since being uploaded on the npm portal. The packages names were:

plutov-slack-client
nodetest199
nodetest1010

"Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer," the npm security team said.