4 ms·

It's not like organizations writing proprietary software are magically immune to sleeper agents either. Social engineering is not a software or tech problem in

It's not like organizations writing proprietary software are magically immune to sleeper agents either. Social engineering is not a software or tech problem in general. Trust is required to get anything done, and can also be abused to hell and back by a sufficiently motivated actor. But important software needs to be identified and proportionally more scrutinized by multiple independent parties, that's the lesson. Identification is the hard part. You can't easily determine that half of the world relies on this particular piece of software, or that it enables access to desirable targets.

b112 3y ago
This is why OSS can be more secure. How much software has the build scripts, the code, all of it, locked away and hidden behind propriety software? Instead of lots of eyes, just 2 DEVs? Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to even dig further? Would he have known what was happening, or would it have just ended up as an oddity, with no source code, and with the binary purposefully obscured, and so on? Or... even worse, it's reported directly to the 2 guy team, and the guy who put the back door in... takes the bug report?! From where I sit the sleeper/mole problem exists in companies, and can be far harder to detect.
- creato 3y ago
  I think there are huge factors that push things both for and against open source here. Yes, you get more eyes and people like Andres Freund. However, if this had been a mole in a company, he wouldn't be able to hide behind a possibly anonymous fake persona and (likely) be immune from any consequences/fallout from this attack. It would be harder to gain entry in the first place, he would have needed a real identity. Background checks may not be a big hurdle, but they're at least something more than signing up for a GitHub account. He also wouldn't have had his posse of anonymous sock puppet accounts to add pressure to the original maintainer. I also think that just being able to ramp up on liblzma and its dependencies to undertake this effort in the first place is a huge head start vs. trying to execute the same attack on a closed source corporate product. At the same time, there are probably lower hanging fruits to attack if you really do get a mole inside a company, in addition to there being fewer eyes/opportunities for the attacks to be discovered as you pointed out. I honestly don't know how all of these factors add up. I expect the argument opposite to yours to be raised (again) in the wake of this incident. I'd personally be hesitant to raise this argument (not that it matters here on HN).
  - A1kmm 3y ago
    > However, if this had been a mole in a company, he wouldn't be able to hide behind a > possibly anonymous fake persona and (likely) be immune from any consequences/fallout from > this attack. It would be harder to gain entry in the first place, he would have needed a > real identity. Lots of companies hire remote workers sight unseen, and not all require proof of identity, and where they do, that proof can possibly be easily faked by someone willing to break the law. Larger Open Source projects - e.g. Debian Developers, also have real-identity verification through chain of trust. > Background checks may not be a big hurdle, but they're at least something more than > signing up for a GitHub account. GitHub doesn't allow more than one free account per person. Companies might not look for employees sharing an IP address as much as GitHub does. > He also wouldn't have had his posse of anonymous sock > puppet accounts to add pressure to the original maintainer. Depending on the software, it might not be that hard to be a customer (or even pretend to be an employee of a known customer, if they aren't validating incoming requests claiming to be from customers enough) and add pressure for features that will provide cover for a backdoor, or even for a product that isn't a commercial success to be handed over to an external developer.
  - WesolyKubeczek 3y ago
    And yet industrial espionage in companies is quite common, by both competition and, if you’re big and important enough, state (yours or enemy). The means are different, though.
  - nonrandomstring 3y ago
    Organisations shield moles and infiltrators very effectively. They are rarely alone. It may be harder to get in as an outsider, but once in they've protections a lone wolf does not enjoy. You can save a lot of time reading John LeCarre novels and take a short summary like this one of Adam Curtis [0]. If you watched the recent Oppenheimer film you'll know the name Klaus Fuchs. But what about Guy Burgess, Kim Philby and Anthony Blunt? If MI5, MI6 and GCHQ are. almost by tradition stacked to the rafters with defectors and spies, enclaves of enemies within, and enemies within enclaves of enemies... how does anyone expect a commercial company motivated by money and with such a weak perimeter as a "job market", to do better? Trust does not have an organisational solution. [0] https://www.bbc.co.uk/blogs/adamcurtis/entries/3662a707-0af9-3149-963f-47bea720b460 https://www.bbc.co.uk/blogs/adamcurtis/entries/3662a707-0af9...
- stavros 3y ago
  I see people saying "this almost succeeded". It didn't almost succeed, it succeeded entirely. It made it to production, for a long time (? I'm not sure how long it was in repos). Success is making it to some machine, and then it's "how long it's successful for". Who knows how many other such vulnerabilities there are, and the openness of the source didn't protect us as quickly as we thought it would.
  - cassianoleal 3y ago
    > It made it to production, for a long time Did it? At least in Debian, where it was found in the first place, it only existed in sid/unstable and I think perhaps in testing. It never made it into stable which is the only thing you should be running on a production system. I think in Fedora it was also only in a testing or RC of the next stable version but I'm not sure. Also unsure about others. I have seen several distros putting out advisories (Gentoo, Arch, OpenSuse and more) but I didn't go into the specifics.
    - stavros 3y ago
      I don't know specifics either, but Debian stable has years-old packages, so I'm not sure if it's a good indicator of how widespread this got. If it's in the latest Ubuntu release, I'd say it's pretty successful.
      - spacemanspiff01 3y ago
        My impression is that it did not get into latest Ubuntu, they were in the process of trying though. The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)
      - mikeocool 3y ago
        Fortunately, it didn’t make it into an Ubuntu release: https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714 https://discourse.ubuntu.com/t/xz-liblzma-security-update/43... Though it was frighteningly close, 24.04 is scheduled to be released on April 25.
- cqqxo4zV46cp 3y ago
  It’s pretty intellectually dishonest to call this a big win for open source. It’s completely and utterly bonkers that this was noticed. Unthinkably low odds. There are certainly other backdoors out there like this, already in production. If this happened on a proprietary software project, …I have verified proof of identity documents for everyone on my team. These can of course be faked or fraudulently obtained, but it heightens the barrier to entry and leaves more of a paper trail. That’s not something that we have in this scenario. There’s way more give and take between open and closed source than open source purists make out. They just like the idea of being able to see source code.
- supriyo-biswas 3y ago
  > Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to even dig further? You should check the thread posted yesterday, the Lastpass guy who raised a PR for a go binding for xz but was otherwise unrelated to this fiasco already faced a bit of questioning regarding their motivations from their employer based on a user reporting them from a contact form. Moreover, many companies already have information from background checks, and in certain countries, they also have the tax identification number of the employee which can pretty much identify who put in the backdoor.
o11c 3y ago
True, but organizations tend not to accept online-only identities.

b112 3y ago

This is why OSS can be more secure. How much software has the build scripts, the code, all of it, locked away and hidden behind propriety software? Instead of lots of eyes, just 2 DEVs? Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to even dig further? Would he have known what was happening, or would it have just ended up as an oddity, with no source code, and with the binary purposefully obscured, and so on? Or... even worse, it's reported directly to the 2 guy team, and the guy who put the back door in... takes the bug report?! From where I sit the sleeper/mole problem exists in companies, and can be far harder to detect.

creato 3y ago
I think there are huge factors that push things both for and against open source here. Yes, you get more eyes and people like Andres Freund. However, if this had been a mole in a company, he wouldn't be able to hide behind a possibly anonymous fake persona and (likely) be immune from any consequences/fallout from this attack. It would be harder to gain entry in the first place, he would have needed a real identity. Background checks may not be a big hurdle, but they're at least something more than signing up for a GitHub account. He also wouldn't have had his posse of anonymous sock puppet accounts to add pressure to the original maintainer. I also think that just being able to ramp up on liblzma and its dependencies to undertake this effort in the first place is a huge head start vs. trying to execute the same attack on a closed source corporate product. At the same time, there are probably lower hanging fruits to attack if you really do get a mole inside a company, in addition to there being fewer eyes/opportunities for the attacks to be discovered as you pointed out. I honestly don't know how all of these factors add up. I expect the argument opposite to yours to be raised (again) in the wake of this incident. I'd personally be hesitant to raise this argument (not that it matters here on HN).
- A1kmm 3y ago
  > However, if this had been a mole in a company, he wouldn't be able to hide behind a > possibly anonymous fake persona and (likely) be immune from any consequences/fallout from > this attack. It would be harder to gain entry in the first place, he would have needed a > real identity. Lots of companies hire remote workers sight unseen, and not all require proof of identity, and where they do, that proof can possibly be easily faked by someone willing to break the law. Larger Open Source projects - e.g. Debian Developers, also have real-identity verification through chain of trust. > Background checks may not be a big hurdle, but they're at least something more than > signing up for a GitHub account. GitHub doesn't allow more than one free account per person. Companies might not look for employees sharing an IP address as much as GitHub does. > He also wouldn't have had his posse of anonymous sock > puppet accounts to add pressure to the original maintainer. Depending on the software, it might not be that hard to be a customer (or even pretend to be an employee of a known customer, if they aren't validating incoming requests claiming to be from customers enough) and add pressure for features that will provide cover for a backdoor, or even for a product that isn't a commercial success to be handed over to an external developer.
- WesolyKubeczek 3y ago
  And yet industrial espionage in companies is quite common, by both competition and, if you’re big and important enough, state (yours or enemy). The means are different, though.
- nonrandomstring 3y ago
  Organisations shield moles and infiltrators very effectively. They are rarely alone. It may be harder to get in as an outsider, but once in they've protections a lone wolf does not enjoy. You can save a lot of time reading John LeCarre novels and take a short summary like this one of Adam Curtis [0]. If you watched the recent Oppenheimer film you'll know the name Klaus Fuchs. But what about Guy Burgess, Kim Philby and Anthony Blunt? If MI5, MI6 and GCHQ are. almost by tradition stacked to the rafters with defectors and spies, enclaves of enemies within, and enemies within enclaves of enemies... how does anyone expect a commercial company motivated by money and with such a weak perimeter as a "job market", to do better? Trust does not have an organisational solution. [0] https://www.bbc.co.uk/blogs/adamcurtis/entries/3662a707-0af9-3149-963f-47bea720b460 https://www.bbc.co.uk/blogs/adamcurtis/entries/3662a707-0af9...
stavros 3y ago
I see people saying "this almost succeeded". It didn't almost succeed, it succeeded entirely. It made it to production, for a long time (? I'm not sure how long it was in repos). Success is making it to some machine, and then it's "how long it's successful for". Who knows how many other such vulnerabilities there are, and the openness of the source didn't protect us as quickly as we thought it would.
- cassianoleal 3y ago
  > It made it to production, for a long time Did it? At least in Debian, where it was found in the first place, it only existed in sid/unstable and I think perhaps in testing. It never made it into stable which is the only thing you should be running on a production system. I think in Fedora it was also only in a testing or RC of the next stable version but I'm not sure. Also unsure about others. I have seen several distros putting out advisories (Gentoo, Arch, OpenSuse and more) but I didn't go into the specifics.
  - stavros 3y ago
    I don't know specifics either, but Debian stable has years-old packages, so I'm not sure if it's a good indicator of how widespread this got. If it's in the latest Ubuntu release, I'd say it's pretty successful.
    - spacemanspiff01 3y ago
      My impression is that it did not get into latest Ubuntu, they were in the process of trying though. The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)
    - mikeocool 3y ago
      Fortunately, it didn’t make it into an Ubuntu release: https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714 https://discourse.ubuntu.com/t/xz-liblzma-security-update/43... Though it was frighteningly close, 24.04 is scheduled to be released on April 25.
cqqxo4zV46cp 3y ago
It’s pretty intellectually dishonest to call this a big win for open source. It’s completely and utterly bonkers that this was noticed. Unthinkably low odds. There are certainly other backdoors out there like this, already in production. If this happened on a proprietary software project, …I have verified proof of identity documents for everyone on my team. These can of course be faked or fraudulently obtained, but it heightens the barrier to entry and leaves more of a paper trail. That’s not something that we have in this scenario. There’s way more give and take between open and closed source than open source purists make out. They just like the idea of being able to see source code.
supriyo-biswas 3y ago
> Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to even dig further? You should check the thread posted yesterday, the Lastpass guy who raised a PR for a go binding for xz but was otherwise unrelated to this fiasco already faced a bit of questioning regarding their motivations from their employer based on a user reporting them from a contact form. Moreover, many companies already have information from background checks, and in certain countries, they also have the tax identification number of the employee which can pretty much identify who put in the backdoor.

o11c 3y ago

True, but organizations tend not to accept online-only identities.