7 ms·

Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please r

Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released. Reading that in a different light, it says give me time to adjust my exploits and capitalize on any targets. Makes me wonder what other vulns might exist in the author's other projects.

xyst 3y ago
90 day dark window for maintainers is SOP though. Then after 90 days, it’s free game for public disclosure
szundi 3y ago
How many of people like this one exist?
- ldayley 3y ago
  If this question had a reliable (and public) answer then the world would be a very different place! That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing. Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic paranoia. We live in a world where we have to trust strangers every day, and if we lose that option completely then our civilization grinds to a halt. But-- vigilance is warranted. I applaud these engineers who followed their instincts and dug into this. They all did us a huge service! EDIT: wording, spelling
  - josephg 3y ago
    Yeah thanks for saying this; I agree. And as cliche as it is to look for a technical solution to a social problem, I also think better tools could help a lot here. The current situation is ridiculous - if I pull in a compression library from npm, cargo or Python, why can that package interact with my network, make syscalls (as me) and read and write files on my computer? Leftpad shouldn’t be able to install crypto ransomware on my computer. To solve that, package managers should include capability based security. I want to say “use this package from cargo, but refuse to compile or link into my binary any function which makes any syscall except for read and write. No open - if I want to compress or decompress a file, I’ll open the file myself and pass it in.” No messing with my filesystem. No network access. No raw asm, no trusted build scripts and no exec. What I allow is all you get. The capability should be transitive. All dependencies of the package should be brought in under the same restriction. In dynamic languages like (server side) JavaScript, I think this would have to be handled at runtime. We could add a capability parameter to all functions which issue syscalls (or do anything else that’s security sensitive). When the program starts, it gets an “everything” capability. That capability can be cloned and reduced to just the capabilities needed. (Think, pledge). If I want to talk to redis using a 3rd party library, I pass the redis package a capability which only allows it to open network connections. And only to this specific host on this specific port. It wouldn’t stop all security problems. It might not even stop this one. But it would dramatically reduce the attack surface of badly behaving libraries.
    - Guvante 3y ago
      Doesn't this exact exploit not fixed by your capability theory? It is hijacking a process that has network access at runtime not build time. The build hack grabs files from the repo and inspects build parameters (in a benign way, everyone checks whether you are running on X platform etc)
      - josephg 3y ago
        The problem we have right now is that any linked code can do anything, both at build time and at runtime. A good capability system should be able to stop xz from issuing network requests even if other parts of the process do interact with the network. It certainly shouldn't have permission to replace crc32_resolve() and crc64_resolve() via ifunc. Another way of thinking about the problem is that right now every line of code within a process runs with the same permissions. If we could restrict what 3rd party libraries can do - via checks either at build time or runtime - then supply chain attacks like this would be much harder to pull off.
        im3w1l 3y ago
        I'm not convinced this is such a cure-all as any library must necessarily have the ability to "taint" its output. Like consider this library. It's a compression library. You would presumably trust it to decompress things right? Like programs? And then you run those programs with full permission? Oops..
        josephg 3y ago
        It’s not a cure-all. I mean, we’re talking about infosec - so nothing is. But that said, barely any programs need the ability to execute arbitrary binaries. I can’t remember the last time I used eval() in JavaScript. I agree that it wouldn’t stop this library from injecting backdoors into decompressed executables. But I still think it would be a big help anyway. It would stop this attack from working. At the big picture, we need to acknowledge that we can’t implicitly trust opensource libraries on the internet. They are written by strangers, and if you wouldn’t invite them into your home you shouldn’t give them permission to execute arbitrary code with user level permissions on your computer. I don’t think there are any one size fits all answers here. And I can’t see a way to make your “tainted output” idea work. But even so, cutting down the trusted surface area from “leftpad can cryptolocker your computer” to “Leftpad could return bad output” sounds like it would move us in the right direction.
  - saalweachter 3y ago
    Assume 3% of the population is malicious. Enough to be cautious, enough to think about how to catch bad actors, not so much as to close yourself off and become a paranoid hermit.
    - pizzafeelsright 3y ago
      Huh. I never really thought of it as a percentage. I've been evil, been wonderful, and indifferent at different stages in life. I have known those who have done similar for money, fame, and boredom. I think, given a backstory, incentive, opportunity, and resources it would be possible to most people to flip from wouldn't to enlisted. Leverage has shown to be the biggest lever when it comes to compliance.
      - XorNot 3y ago
        It's doubtful you've been evil, or at least, you are really lacking in imagination of the true scope of what that word implies.
      - mlsu 3y ago
        The line between good and evil cuts through the heart of every person
      - saulpw 3y ago
        "Assume that 3% of the people you encounter will act maliciously."
    - heresie-dabord 3y ago
      We live in a time of populous, wealthy dictatorships that have computer-science expertise are openly hostile to the US and Canada. North America is only about 5% of the world's population. [1] (We can assume that malicious actors are in North America, too, but this helps to adjust our perspective.) The percentage of maliciousness on the Internet is much higher. [1] _ See continental subregions. https://en.wikipedia.org/wiki/List_of_continents_and_continental_subregions_by_population https://en.wikipedia.org/wiki/List_of_continents_and_contine...
  - heresie-dabord 3y ago
    Threat actors create personas. We will need strong social trust to protect our important projects and dependencies.
  - account42 3y ago
    > We, particularly those us who work on critical infrastructure or software We should also be asking ourselves if we are working on critical infrastructure. Lasse Collin probably did not consider liblzma being loaded by sshd when vetting the new maintainer. Did the xz project ever agree to this responsibility? We should also be asking ourselfs if each dependency of critical infrastructure is worth the risk. sshd linking libsystemd just to write a few bytes into an open fd is absurd. libsystemd pulling in liblzma because hey it also does compressed logging is absurd. Yet this kind of absurd dependency bloat is everywhere.
- hulitu 3y ago
  > How many of people like this one exist? I guess every 3 letter agency has at least one. You can do the math. They havent't learned anything after Solar Winds.
ncr100 3y ago
Security Researchers: Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.
- bawolff 3y ago
  Whether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited. This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
  - londons_explore 3y ago
    If you were following Google Project Zero's policy (which many researchers do), any in-the-wild exploits would trigger an immediate reveal.
  - larschdk 3y ago
    Detecting a security issue is one thing. Detecting a malicious payload is something completely different. The latter has intent to exploit and must be addressed immediately. The former has at least some chance of noone knowing about it.
- cjbprime 3y ago
  In this particular case, there is a strong reason to expect exploitation in the wild to already be occurring (because it's an intentional backdoor) and this would change the risk calculus around disclosure timelines. But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
  - ang_cire 3y ago
tw04 3y ago
Honestly it seems like a state-based actor hoping to get whatever high value target compromised before it's made public. Reporting privately buys them more time, and allows them to let handlers know when the jig is up.

xyst 3y ago

90 day dark window for maintainers is SOP though. Then after 90 days, it’s free game for public disclosure

szundi 3y ago

How many of people like this one exist?

ldayley 3y ago
If this question had a reliable (and public) answer then the world would be a very different place! That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing. Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic paranoia. We live in a world where we have to trust strangers every day, and if we lose that option completely then our civilization grinds to a halt. But-- vigilance is warranted. I applaud these engineers who followed their instincts and dug into this. They all did us a huge service! EDIT: wording, spelling
- josephg 3y ago
  Yeah thanks for saying this; I agree. And as cliche as it is to look for a technical solution to a social problem, I also think better tools could help a lot here. The current situation is ridiculous - if I pull in a compression library from npm, cargo or Python, why can that package interact with my network, make syscalls (as me) and read and write files on my computer? Leftpad shouldn’t be able to install crypto ransomware on my computer. To solve that, package managers should include capability based security. I want to say “use this package from cargo, but refuse to compile or link into my binary any function which makes any syscall except for read and write. No open - if I want to compress or decompress a file, I’ll open the file myself and pass it in.” No messing with my filesystem. No network access. No raw asm, no trusted build scripts and no exec. What I allow is all you get. The capability should be transitive. All dependencies of the package should be brought in under the same restriction. In dynamic languages like (server side) JavaScript, I think this would have to be handled at runtime. We could add a capability parameter to all functions which issue syscalls (or do anything else that’s security sensitive). When the program starts, it gets an “everything” capability. That capability can be cloned and reduced to just the capabilities needed. (Think, pledge). If I want to talk to redis using a 3rd party library, I pass the redis package a capability which only allows it to open network connections. And only to this specific host on this specific port. It wouldn’t stop all security problems. It might not even stop this one. But it would dramatically reduce the attack surface of badly behaving libraries.
  - Guvante 3y ago
    Doesn't this exact exploit not fixed by your capability theory? It is hijacking a process that has network access at runtime not build time. The build hack grabs files from the repo and inspects build parameters (in a benign way, everyone checks whether you are running on X platform etc)
    - josephg 3y ago
      The problem we have right now is that any linked code can do anything, both at build time and at runtime. A good capability system should be able to stop xz from issuing network requests even if other parts of the process do interact with the network. It certainly shouldn't have permission to replace crc32_resolve() and crc64_resolve() via ifunc. Another way of thinking about the problem is that right now every line of code within a process runs with the same permissions. If we could restrict what 3rd party libraries can do - via checks either at build time or runtime - then supply chain attacks like this would be much harder to pull off.
      - im3w1l 3y ago
        I'm not convinced this is such a cure-all as any library must necessarily have the ability to "taint" its output. Like consider this library. It's a compression library. You would presumably trust it to decompress things right? Like programs? And then you run those programs with full permission? Oops..
        josephg 3y ago
        It’s not a cure-all. I mean, we’re talking about infosec - so nothing is. But that said, barely any programs need the ability to execute arbitrary binaries. I can’t remember the last time I used eval() in JavaScript. I agree that it wouldn’t stop this library from injecting backdoors into decompressed executables. But I still think it would be a big help anyway. It would stop this attack from working. At the big picture, we need to acknowledge that we can’t implicitly trust opensource libraries on the internet. They are written by strangers, and if you wouldn’t invite them into your home you shouldn’t give them permission to execute arbitrary code with user level permissions on your computer. I don’t think there are any one size fits all answers here. And I can’t see a way to make your “tainted output” idea work. But even so, cutting down the trusted surface area from “leftpad can cryptolocker your computer” to “Leftpad could return bad output” sounds like it would move us in the right direction.
- saalweachter 3y ago
  Assume 3% of the population is malicious. Enough to be cautious, enough to think about how to catch bad actors, not so much as to close yourself off and become a paranoid hermit.
  - pizzafeelsright 3y ago
    Huh. I never really thought of it as a percentage. I've been evil, been wonderful, and indifferent at different stages in life. I have known those who have done similar for money, fame, and boredom. I think, given a backstory, incentive, opportunity, and resources it would be possible to most people to flip from wouldn't to enlisted. Leverage has shown to be the biggest lever when it comes to compliance.
    - XorNot 3y ago
      It's doubtful you've been evil, or at least, you are really lacking in imagination of the true scope of what that word implies.
    - mlsu 3y ago
      The line between good and evil cuts through the heart of every person
    - saulpw 3y ago
      "Assume that 3% of the people you encounter will act maliciously."
  - heresie-dabord 3y ago
    We live in a time of populous, wealthy dictatorships that have computer-science expertise are openly hostile to the US and Canada. North America is only about 5% of the world's population. [1] (We can assume that malicious actors are in North America, too, but this helps to adjust our perspective.) The percentage of maliciousness on the Internet is much higher. [1] _ See continental subregions. https://en.wikipedia.org/wiki/List_of_continents_and_continental_subregions_by_population https://en.wikipedia.org/wiki/List_of_continents_and_contine...
- heresie-dabord 3y ago
  Threat actors create personas. We will need strong social trust to protect our important projects and dependencies.
- account42 3y ago
  > We, particularly those us who work on critical infrastructure or software We should also be asking ourselves if we are working on critical infrastructure. Lasse Collin probably did not consider liblzma being loaded by sshd when vetting the new maintainer. Did the xz project ever agree to this responsibility? We should also be asking ourselfs if each dependency of critical infrastructure is worth the risk. sshd linking libsystemd just to write a few bytes into an open fd is absurd. libsystemd pulling in liblzma because hey it also does compressed logging is absurd. Yet this kind of absurd dependency bloat is everywhere.
hulitu 3y ago
> How many of people like this one exist? I guess every 3 letter agency has at least one. You can do the math. They havent't learned anything after Solar Winds.

ncr100 3y ago

Security Researchers: Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.

bawolff 3y ago
Whether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited. This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
- londons_explore 3y ago
  If you were following Google Project Zero's policy (which many researchers do), any in-the-wild exploits would trigger an immediate reveal.
- larschdk 3y ago
  Detecting a security issue is one thing. Detecting a malicious payload is something completely different. The latter has intent to exploit and must be addressed immediately. The former has at least some chance of noone knowing about it.
cjbprime 3y ago
In this particular case, there is a strong reason to expect exploitation in the wild to already be occurring (because it's an intentional backdoor) and this would change the risk calculus around disclosure timelines. But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
- ang_cire 3y ago

tw04 3y ago

Honestly it seems like a state-based actor hoping to get whatever high value target compromised before it's made public. Reporting privately buys them more time, and allows them to let handlers know when the jig is up.