422
Oh Snap! Canonical now doing manual reviews for new packages due to scam apps (www.gamingonlinux.com)
submitted 2 years ago by to c/linux@lemmy.ml
145 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 2 years ago (6 children)

The use of MD5 becomes a bigger issue when paired with the lack of package signatures. You can inject code into a package and find a colliding digest absurdly fast. I and a friend from Threatlocker created a Metasploit module to use Deb packages for local privesc based on the concept. If it touches the filesystem outside of the APT cache it becomes a vector.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 4 points 2 years ago (5 children)

    Absolutely this. I wasn't aware that Debs were still using MD5s and am now quite disturbed by this. Time to dig through some source.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 5 points 2 years ago (4 children)

    In theory (whitepaper is still being written), if you MITM the connection to the APT mirror it's using you can also carry out the attack over the network by injecting it into the package on the fly. Cert pinning might be a blocker, but local (LAN) package mirrors might still be valid attack targets. Enterprises often use MITM certs for things like DLP and packet inspection we might be able to leverage at least.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 2 years ago (3 children)

    Yeah. This is a pretty big issue. Proper handling of MitM certs via a trusted root CA on the enterprise machines could mitigate a bit by avoiding use of TLS skip-verify but, there's still a wider threat surface than there should be due to the use of MD5. Sub-second collisions means that malicious code could be readily inserted by an adversary through something like that xz backdoor and likely go unnoticed for much longer.

    Time to figure out contributing to Debian.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 2 years ago (2 children)

    To save you some effort, they do not consider it a priority to fix. Code was attempted to merge that would make package signatures the default, but it was removed because it “was a waste of cpu cycles” when “md5 and the https was just as good”. I’m not kidding, you can find the whole conversation in the Debian mailing archives. So instead I’m going to make it known how dumb it is, and encourage people to use something else.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    Oh my. That's extremely disappointing. I love the project but part of making software free and accessible is ensuring that trust is reasonable to place in it. I'll probably still see if I can get my head around dpkg enough to fork it to replace MD5 with an actually secure hashing algorithm and make signing mandatory. I've found what I think is the file specification already (my C is in need of exercising) and I've been waiting too long for my with to get back to me on contributing to open source projects so, this could be a good one.

    Please do share the white paper when published. I'm looking forward to that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 years ago*

    I admire your gusto! I think it's doable, and you can definitely pull it off if you want to. To replace MD5 and implement signatures you need to do the following, as a high level overview:

    Extend dpkg to know what SHA2 is, and reliably detect it. (maybe measure hash length or specifying a new version using the control file?)

    dpkg must also know what a signature is. More on that below.

    Providing automatic/mandatory signing will require code to handle PKI as well as a place to store the signing information. I would do it by signing the two archives found within Deb packages, then placing information about the signing in the top-level of the package. Existing tools need to be able to ignore or handle whatever you implement as a rule of thumb.

    Note that this is just my approach and maybe you can do better.

    I also recommended looking into https://lists.debian.org/debian-dpkg/2001/03/msg00024.html. This is the thread I mentioned earlier, in which package signatures were discussed and ultimately turned down. Maybe the easiest approach is to re-implement what the contributor was trying to do back then, but with modern code and standards? If you want more resources, including my presentation on the topic to HackCFL and CitrusSec, let me know. I am here for whatever technical assistance or industry contacts I can provide. The white paper might be done in a month, minus peer review. I'm very busy and so is he. Good luck in any case!

  • permalink
  • fedilink
  • source
  • parent