19

Linux Mint was compromised and a backdoored ISO was deployed, Ubuntu was compromised, the entire Linux Kernel was compromised before, as were others (Debian, FreeBSD, etc). Developers protect code through checks and balances in what code is accepted into the mainline source code repository, and checksums. The issues revolve around whether or not an attacker ...


11

Could malicious code be pushed to NPM? Most certainly. If a package is to become compromised (or a new one is published), installed, and used any code provided with that package could be executed. So if they run it in the node.js context for example, the attack has access to many machine level features such as the file system, system information, file ...


10

If I am understanding your question correctly, it boils down to: Homebrew changes the permissions of /usr/local/bin from the default drwxr-xr-x root wheel to the less secure drwxrwxr-x myuser admin. What are the risks? As you point out, your user (or anyone in the admin group, or any virus that manages to run as you) can now install software, including ...


6

It isn't. The threat model attempts to be resistant to external attack, but if all it takes is a malicious line in a build script on a package used on most systems (e.g. libc, x11, etc.) then all they need to do is compromise one build machine to gain near-universal control. Attempting to protect against this is hard, and the only way to do it is to build ...


6

The adding of the repository itself is not dangerous. But you will probably do an apt update and apt upgrade (or similar) sometimes after you've added the repository. The apt upgrade will cause any software already existing on the system to be updated with a newer version if possible - no matter if this newer version comes from the same repository as the ...


6

Linux Mint founder and lead developer Clement Lefebvre responded to these accusations with a blog post on segfault.linuxmint.com in 2013. I hear [Oliver Grawert, a Canonical-employed Ubuntu developer] was more opinionated than knowledgeable and the press blew what he said out of proportion. I wouldn’t mind too much, if we weren’t finding ourselves answering ...


5

If I wanted to avoid such risks, would it be safer to clone the git repository of the source code for the gem, and build the gem myself? Probably not. More effort is likely to go into releasing (and potentially approving) a gem for inclusion onto rubygems than you will go to when cloning the source, especially for popular gems. Furthermore, there might be ...


5

The short answer is: pip always uses TLS, which is actually fairly useful here. It means that as long as no-one's managed to compromise PyPI itself or steal the site certificate, then you can be certain that the packages you download are the ones that the PyPI admins think are correct. And it's hard to do better than that: after all, the PyPI admins are the ...


4

Three words: Supply Chain Management. Except that in our case the "supply" is dependency or "third party libraries". This isn't a unique problem to npm. This a general problem in software development. It's the equivalent of googling for a manufacturer of "screws" then use the first manufacturer of "screws" you see, don't ask about the specs of the "screws",...


4

The risks are the same as with other language-specific package management systems (npm for node.js, pypi for python, CRAN for R, CPAN for perl etc.) Yet, it is very often prudent to install this stuff without superuser's privileges, or at least have the chance to review what is being installed. To do the review one may use an utility like fpm to roll up an ....


4

Sort of... Firstly, Pypi includes a hash of the file being downloaded, so that any modifications/errors between server and client will be spotted. Secondly, pip has support for a hash-checking mode where you can specify the required hash for the requested package in requirements.txt in the form: Foo==1.2.3 --hash=sha256:xxxxxxx pip will then verify that ...


3

RHSM is the new x509 based PKI solution to their older RHN subscription manager. Unlike RHN which provided authorization only for registered systems, RHSM provides authentication, authorization and repudiation based on certificates. Those certificates rely on your typical asymmetric encryption making use of private and public keys to generate and sign the ...


3

I setup MITM for pip to pypi.python.org and it seems that pip does indeed validate the certificate. It fails with SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]. Maybe I will have more luck with other repositories... Pip may not be checking gpg signatures but it's not like you are downloading from untrusted sources. For example, Linux packages are spread across ...


3

What security does self-hosting provide if I already trust the package author & contents? Including content from a third party system outside of your control does not only mean that you need to trust the authors of the content to not willingly add malicious content but that you also need to trust them to keep their systems available and secure. In other ...


3

PyCharm does not automatically install packages. What very likely happened is that you added import sklearn to the top of your file, and then used the install package quickfix. After you add an unresolved import, a red light bulb will appear, and you can choose to install the package with the name of your import, in this case sklearn. The other ways to ...


3

Microsoft published a white paper describing a few mitigation strategies. To summarize them: Make use of a single dependency source instead of multiple: The idea here is to configure your package manger (e.g. via the pip config file) to only pull packages from a singular repository you control or trust. I guess in the "best" case you'd restrict it ...


3

There are two types of cryptographic validation here: Apt supports that each developer signs the package with its own key, and to validate that on package install. This is what this file refers to and is not used (currently) by Debian, Ubuntu, etc. The repository manifest is cryptographically signed with a repository key (see apt-secure(8)) and that ...


2

From this link Redhat suggests: Red Hat does provide a high level of security in the operating system and packages that they distribute. As security issues are discovered in various applications (and presumably in packages), Red Hat provides updated packages in a way which keeps potential risk to a minimum; Red Hat Enterprise Linux 3 and higher employs ...


2

Linux has a list of trusted root CA in /etc/ssl/certs or similar locations. Various applications (like browsers) or programming languages (like Java) come with their own CA store while others use the systems CA store. This "Synchronize local certs with certs from local Linux trust store." probably just means that Mono imports the system certificates into its ...


2

TL;DR: In principle u20 and any package with a higher number should not be vulnerable (hell, u1 and any higher should not be vulnerable since the upstream version of the package does not change and u1 is not vulnerable). That is, unless VVV (the upstream version, see below) changes or you change your Debian release, in which case a different numbering is ...


2

By itself, no, the act of adding a new repo too the repo manager isn't particularly dangerous.. and it can be argued that adding a repo from a reputable source and following through with an upgrade/install after that repo has been trusted isn't even dangerous. The inherent problem is adding every and all repos that say they offer the newest versions of ...


2

Basically the issue here is that 3rd party software tried to steal private information and send it out over the network. This issue is not unique to npm, any software running as your computer users could really do the same since there's nothing to stop it from reading your user data. As a line of defense against such an attack, you might consider using an ...


2

Supply chain management is the right answer in theory, however, despite the efforts of commercial entities like snyk and many others, there is no solution to this problem in the node ecosystem in practice. Node's supply chain record, with no disrespect intended to the numerous folks working to make it better, is uniquely awful. King of that infamous ...


2

There is the Ubuntu Security Advisory. It provides a mailing list, RSS feed, and Atom feed. There is no API for historical data, according to a similar question on AskUbuntu.


2

They matter. Not updating libraries and dependencies will leave your software vulnerable. Each one of the libraries is part of the attack surface. Unless an update breaks your code, update as soon as the update is available. If the update breaks your code, patch the code and update. But never leave any outdated library with security bugs in your projects. ...


2

The problem is independent of what technique you use to obtain your JS libraries. It doesn't matter if you use NPM packages, web-pack or manually copy&paste a folder of .js files. The problem is with using 3rd party code from untrustworthy sources and putting them into your web application without making sure they don't contain any malicious ...


2

Is it a good counter-measure for this kind of a situation? No. Unfortunately what you're planning to do won't address this specific threat. Here, the attackers compromised the package on PyPI itself, hence it was downloaded from the original source, so limiting downloads only to PyPI would have no effect. In most cases, these compromised packages come in ...


2

The Gradle team published a paper discussing some of the mitigation strategies as it relates to Gradle and Maven. They talk about a wide range of topics like signing commits, disposable containers, build caches, etc. But getting to how to mitigate this particular attack here were some highlights: Verifying dependencies with Gradle's trusted-key Repository ...


1

You can change your path order in /etc/paths to prevent such malicious behaviour. However $PATH could be overrided in shell script (like .bash_profile or .zshrc) so check/change them too. Regarding Macports - I prefer to run untrusted software in a userspace with minimal privileges, so Homebrew is more suitable. Regarding Unix shell - just build a chain of ...


1

That depends on what the dependencies are and what they're used for. Even if a dependency isn't used in production, if it's used as part of your build process, for example, then its possible that it might contain a vulnerability that affects your production code. Similarly, a vulnerability in a development tool could potentially allow attackers to ...


Only top voted, non community-wiki answers of a minimum length are eligible