4 ms·

So I'm glad this is being done, but the "attack surface" that's being resolved sounds like a bit of a joke... "Alice, a system administrator who contributes to

by geokon 8y ago

So I'm glad this is being done, but the "attack surface" that's being resolved sounds like a bit of a joke... "Alice, a system administrator who contributes to a Linux distribution, is building her binaries on servers that, unknown to her, have been compromised" This is a bit of weird scenario.. so they're assuming the only build being compromised is the one that ends up in the repo and no one can confirm that easily. So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? No need to fuzz the dates and paths and stuff. Or if you really want, you make a special Debian version (super-stable) with fixed clocks, file paths, etc. where things are easy to reproduce. "Bob, a privacy-oriented developer, makes a privacy-preserving browser, but is being blackmailed into secretly including vulnerabilities in the binaries he provides. Carol is a free-software user whose laptop is being attacked by an evil maid called Eve, the third developer of the title; each time Carol shares free software with her friends, it is pre-compromised by Eve" Do Debian contributors just upload a binary blob to the Debian servers and that's it? I though they were saying they have build servers for every package and the source from which it's built is available How about even easier - a bribed/black-mailed Debian maintainer slips in a patch to some of the tens of thousands of packages they tweak, no one notices and it gets distributed to everyone. I'm not expert, but it seems the smarter solution would be to have a much smaller reproducible core/base system (with Debian patches when necessary). Something that can realistically get enough eyeballs on it. And then everything else is built by project maintainers into something like flatpaks/snaps with no patching.

geezerjay 8y ago
> So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? Considering that you are a DNS spoof away from installing packages from a compromised server, how does your proposal tackle the underlying problem?
- danieldk 8y ago
  Considering that you are a DNS spoof away from installing packages from a compromised server, Virtually all package managers now verify package and/or metadata signatures. If a server is spoofed and the system downloads a compromised package, the package manager will simply refuse to install it, because it is not signed by your distribution's packages. Reproducible builds are useful because it reduces the probability of a compromised build system going undetected, by building the package on several independent builders. For the user it also answers the question: does a distributor actually compile from the source code that they claim to compile from?
  - Foxboron 8y ago
    Arch Linux is also working on providing tools so our users can download a package, point a script at it and have the package recreated with all the info provided in .BUILDINFO. This includes the source location and a list of packages present on the system when the package was created. We are a couple of steps away from actually providing this, but we will hopefully get there soon enough.
- dmm 8y ago
  > Considering that you are a DNS spoof away from installing packages from a compromised server, This is false. Debian packages are signed. If the signature fails to validate the package will not install.
  - isostatic 8y ago
    While this is intuitive and obvious those who have used debian (or rather apt) for decades, it seems that a whole generation of computer professionals don't grasp it. Modern software development involves pulling tons of libraries (often at runtime) from other locations. A lot of damage was done by things like 'sudo pip install xxx' and 'curl http://blah.com/install.sh|sudo http://blah.com/install.sh|sudo bash' At least docker's install uses https before downloading some random text from the internet, nowhere near as secure as gpg signing a package though -- compromise the website and you win.
    - eeZah7Ux 8y ago
      > At least docker's install uses https Anybody with a fake email address can upload a bunch of backdoored images on dockerhub and there's no way to spot that.
      - isostatic 8y ago
        Presumably a given repository is secure? At least as much as a https certificate makes it secure (which means a compromise of a docker certificate or website means a compromise of everything on it) This isn't about downloading random crap from the internet, it's about having the communication between who you trust (redhat, microsoft, dave smith) being secure. GPG signing of the code you download means that you are running the code from the person with that GPG key. Doesn't matter if the server the reporistory is on is compromised via a DNS/https hack, or via some other means. The worst that will happen is you download the compromised software, it doesn't match the person/organization you trust, and you delete it.
      - kpcyrd 8y ago
        They get their own namespace, they can't overwrite random existing images.
majewsky 8y ago
> so they're assuming the only build being compromised is the one that ends up in the repo and no one can confirm that easily. So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? In the end, it should be more like 1000+ servers. It's probably quite trivial for a three-letter agency to hack the notebook of one or two open-source contributors. It's less trivial to hack hundreds or thousands of different servers hosted by different people in different regions, with varying amounts of tinfoil.
eeZah7Ux 8y ago
> just have two (or more) identical servers in separate locations under different people's control "just"... The whole point of reproducible builds is for many 3rd parties to be able to rebuild packages easily and get consistent outputs without having to spend months to set up a perfectly "standard" buildbot. Many large orgs are already rebuilding stuff anyways - adding security checks is going to be easy. > No need to fuzz the dates No, you still need to handle that. > a bribed/black-mailed Debian maintainer slips in a patch to some of the tens of thousands of packages they tweak No, other developers and 3rd parties will notice the patch being applied by the build tools.
- lamby 8y ago
  > other developers and 3rd parties will notice the patch being applied by the build tools. Not if it is done to the build servers. The code "looks fine".
lmm 8y ago
> So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? How are you going to make them identical without introducing a point where one person could compromise both of them? > Or if you really want, you make a special Debian version (super-stable) with fixed clocks, file paths, etc. where things are easy to reproduce. Seems like that would be more work. And it would mean everyone would have to trust whoever maintains this super-stable Debian version, so again you're back to trusting one person. > How about even easier - a bribed/black-mailed Debian maintainer slips in a patch to some of the tens of thousands of packages they tweak, no one notices and it gets distributed to everyone. The patches are at least publicly recorded (and I believe signed?) and available for review. Whether anyone is reviewing them is another question, but it's at least possible to do so if you care to. Whereas it's very hard to review the binary build process.
lfam 8y ago
> Do Debian contributors just upload a binary blob to the Debian servers and that's it? The practice has either been eliminated or curtailed but, yes, this was done for a long time.
- lamby 8y ago
  Curtailed... "Source-only uploads" (the term to Google for) are not required. I suspect they are not even the norm due to not being the defaults for various tools, etc.
  - lfam 8y ago
    Thanks for the clarification. My impression as a Debian user was that it had been mostly curtailed. It doesn't matter too much... you either trust your contributors or you don't. But it's still a bit icky.
briffle 8y ago
Reading those examples reminded me of TrueCrypt, and its very strange shutdown: https://en.wikipedia.org/wiki/TrueCrypt https://en.wikipedia.org/wiki/TrueCrypt

by geokon 8y ago

geezerjay 8y ago

> So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? Considering that you are a DNS spoof away from installing packages from a compromised server, how does your proposal tackle the underlying problem?

danieldk 8y ago
Considering that you are a DNS spoof away from installing packages from a compromised server, Virtually all package managers now verify package and/or metadata signatures. If a server is spoofed and the system downloads a compromised package, the package manager will simply refuse to install it, because it is not signed by your distribution's packages. Reproducible builds are useful because it reduces the probability of a compromised build system going undetected, by building the package on several independent builders. For the user it also answers the question: does a distributor actually compile from the source code that they claim to compile from?
- Foxboron 8y ago
  Arch Linux is also working on providing tools so our users can download a package, point a script at it and have the package recreated with all the info provided in .BUILDINFO. This includes the source location and a list of packages present on the system when the package was created. We are a couple of steps away from actually providing this, but we will hopefully get there soon enough.
dmm 8y ago
> Considering that you are a DNS spoof away from installing packages from a compromised server, This is false. Debian packages are signed. If the signature fails to validate the package will not install.
- isostatic 8y ago
  While this is intuitive and obvious those who have used debian (or rather apt) for decades, it seems that a whole generation of computer professionals don't grasp it. Modern software development involves pulling tons of libraries (often at runtime) from other locations. A lot of damage was done by things like 'sudo pip install xxx' and 'curl http://blah.com/install.sh|sudo http://blah.com/install.sh|sudo bash' At least docker's install uses https before downloading some random text from the internet, nowhere near as secure as gpg signing a package though -- compromise the website and you win.
  - eeZah7Ux 8y ago
    > At least docker's install uses https Anybody with a fake email address can upload a bunch of backdoored images on dockerhub and there's no way to spot that.
    - isostatic 8y ago
      Presumably a given repository is secure? At least as much as a https certificate makes it secure (which means a compromise of a docker certificate or website means a compromise of everything on it) This isn't about downloading random crap from the internet, it's about having the communication between who you trust (redhat, microsoft, dave smith) being secure. GPG signing of the code you download means that you are running the code from the person with that GPG key. Doesn't matter if the server the reporistory is on is compromised via a DNS/https hack, or via some other means. The worst that will happen is you download the compromised software, it doesn't match the person/organization you trust, and you delete it.
    - kpcyrd 8y ago
      They get their own namespace, they can't overwrite random existing images.

majewsky 8y ago

> so they're assuming the only build being compromised is the one that ends up in the repo and no one can confirm that easily. So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? In the end, it should be more like 1000+ servers. It's probably quite trivial for a three-letter agency to hack the notebook of one or two open-source contributors. It's less trivial to hack hundreds or thousands of different servers hosted by different people in different regions, with varying amounts of tinfoil.

eeZah7Ux 8y ago

> just have two (or more) identical servers in separate locations under different people's control "just"... The whole point of reproducible builds is for many 3rd parties to be able to rebuild packages easily and get consistent outputs without having to spend months to set up a perfectly "standard" buildbot. Many large orgs are already rebuilding stuff anyways - adding security checks is going to be easy. > No need to fuzz the dates No, you still need to handle that. > a bribed/black-mailed Debian maintainer slips in a patch to some of the tens of thousands of packages they tweak No, other developers and 3rd parties will notice the patch being applied by the build tools.

lamby 8y ago
> other developers and 3rd parties will notice the patch being applied by the build tools. Not if it is done to the build servers. The code "looks fine".

lmm 8y ago

> So just have two (or more) identical servers in separate locations under different people's control so they aren't both compromised? How are you going to make them identical without introducing a point where one person could compromise both of them? > Or if you really want, you make a special Debian version (super-stable) with fixed clocks, file paths, etc. where things are easy to reproduce. Seems like that would be more work. And it would mean everyone would have to trust whoever maintains this super-stable Debian version, so again you're back to trusting one person. > How about even easier - a bribed/black-mailed Debian maintainer slips in a patch to some of the tens of thousands of packages they tweak, no one notices and it gets distributed to everyone. The patches are at least publicly recorded (and I believe signed?) and available for review. Whether anyone is reviewing them is another question, but it's at least possible to do so if you care to. Whereas it's very hard to review the binary build process.

lfam 8y ago

> Do Debian contributors just upload a binary blob to the Debian servers and that's it? The practice has either been eliminated or curtailed but, yes, this was done for a long time.

lamby 8y ago
Curtailed... "Source-only uploads" (the term to Google for) are not required. I suspect they are not even the norm due to not being the defaults for various tools, etc.
- lfam 8y ago
  Thanks for the clarification. My impression as a Debian user was that it had been mostly curtailed. It doesn't matter too much... you either trust your contributors or you don't. But it's still a bit icky.

briffle 8y ago

Reading those examples reminded me of TrueCrypt, and its very strange shutdown: https://en.wikipedia.org/wiki/TrueCrypt https://en.wikipedia.org/wiki/TrueCrypt