6 ms·

Debian Security Advisory: DSA-3025-1 apt

175 points by handsomeransoms 12y ago

ayrx 12y ago
So... Debian users will need to grab security fixes for `apt-get` using... `apt-get`?
- yebyen 12y ago
  I was going to say "you should be OK as long as you ..." But it seems like the CVEs are unavailable, I'm getting 502 Proxy Errors. It seems like four separate attack vectors are addressed in this update. This all is kind of surprising.
  - handsomeransoms 12y ago
    Yeah, I'm having a hard time finding details on the vulnerabilities. A lot of the links in the advisories are broken, and the descriptions on the Mitre CVE pages seem to be awaiting update. Anybody know how to find better descriptions of these bugs, or the patches that fixed them?
    - pja 12y ago
      Here's the relevant changeset in the Debian apt git repo browser: http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=ca7fd76c2f30c100dcf1c12e717ce397cccd690b http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=ca7fd7...
    - VLM 12y ago
      I'm having trouble thinking of a realistic exploit for the first. The second would seem to require not using signing keys which most people have been using for a long time AND the people that are using signing keys (almost everyone) not complaining about bad stuff being substituted in AND the mirror/repo ops not noticing. The third isn't enabled by default and probably doesn't apply to many people. The fourth only applies to people who download and build from source which other than researchers and devs is pretty much no one and is another one of those that relies on everybody not paying attention. (edited to emphasize that the above isn't some kind of formal pronouncement of The Truth, but it is the logic I used when deciding how to prioritize this situation, which ended up with a conclusion of "not very important, not at all". Your situation not being identical to mine will almost certainly result in a somewhat different conclusion, much as my conclusion would be different if I were in your situation instead of mine.) http://www.ubuntu.com/usn/usn-2348-1/ http://www.ubuntu.com/usn/usn-2348-1/ It was discovered that APT did not re-verify downloaded files when the If-Modified-Since wasn't met. (CVE-2014-0487) It was discovered that APT did not invalidate repository data when it switched from an unauthenticated to an authenticated state. (CVE-2014-0488) It was discovered that the APT Acquire::GzipIndexes option caused APT to skip checksum validation. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS, and was not enabled by default. (CVE-2014-0489) It was discovered that APT did not correctly validate signatures when downloading source packages using the download command. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2014-0490)
      - edwintorok 12y ago
        How do you download source packages using the 'download' command? The debian advisory and manpage says that 'download' gives you the binary package, there's another 'apt-get source' command for the source package...
        agwa 12y ago
        The Ubuntu advisory says "source packages" for some reason. I think it's a typo but it doesn't change the analysis - most people don't use 'apt-get download' to install packages.
        mdeslaur 12y ago
        Yes, that was a typo. Thanks for spotting it, I have updated the advisory: http://www.ubuntu.com/usn/usn-2348-1/ http://www.ubuntu.com/usn/usn-2348-1/
        edwintorok 12y ago
        you're right about that I didn't even know that 'apt-get download' existed, closest I ever used was 'apt-get source' :)
        agwa 12y ago
        'apt-get download' is a relatively recent addition.
      - agwa 12y ago
        I concur with your analysis of 2-4. Edit: Regarding #1(If-Modified-Since), the vulnerability is that if a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response, apt will ignore the updated file and continue to use the old version of the file. even though the old version of the file doesn't match the new hash. An attacker could exploit this to prevent a system from receiving updates, though thankfully it doesn't seem to be possible to exploit this to cause apt to trust an arbitrary package. Original incorrect speculation below: Regarding #1 (If-Modified-Since), I'm wondering if perhaps their HTTP client incorrectly accepts a response body with a 304 response (contrary to the HTTP spec)? In that case a malicious server could deliver a file that's blindly trusted as long as it has a status of 304. (This is pure speculation, but I can't think of any other reason this would be a big deal.)
- pja 12y ago
  Slight chicken and egg problem there, agreed. You can check the package signatures for the downloaded debs in /var/cache/apt/archives by following the links for your architecture at the bottom of https://packages.debian.org/wheezy/apt https://packages.debian.org/wheezy/apt (You might need to check the rest of the apt-related debs as well. Just replace apt in the URL with the relevant package name and follow the links at the bottom to get the package hashes. If you're tracking sid instead of wheezy then just replace the distribution name in the URL.)
- seren 12y ago
  if 'libapt' is not the root cause and if it already is installed on your system , you can probably update safely using `aptitude update`.
  - pbhjpbhj 12y ago
    libapt has also been updated and the changelog (accessed via aptitude) is the same as for apt itself. Interestingly both are given "urgency=low" ratings; at least 3 other updates have been medium urgency this year. Edit: sorry should have said on Ubuntu; I've got libapt-inst1.5:amd64 (1.0.1ubuntu2.3) from trusty/main.
    - mdeslaur 12y ago
      The urgency tag isn't used in Ubuntu, only in Debian.
- spain 12y ago
  Correct me if I'm wrong, but can't you just download the packages from https://packages.debian.org/wheezy/apt https://packages.debian.org/wheezy/apt and install them manually using dpkg?
  - pja 12y ago
    Yes, you can definitely do that.
  - cnlwsu 12y ago
    yeah, can be a pain to get the right dependancies in right order etc though. In this case probably easy enough
  - yebyen 12y ago
    If you know how to verify the signatures properly, that would work. I'm thinking if you don't know that, and if you're willing to do what you just described, you probably don't really care about these CVEs anyway.
    - pwnna 12y ago
      Can't you also just verify the sha256 from debian's site? I wrote a script here: https://gist.github.com/shuhaowu/286e6681d6faa473ebb0 https://gist.github.com/shuhaowu/286e6681d6faa473ebb0
      - yebyen 12y ago
        sha256 doesn't provide any web-of-trust; if your download is compromised, the sha-sums that you download to verify them could also be compromised in the same way. If the crypto signatures are verified and your installed keyring is genuine (came from a genuine installation media), then you know that the packages you installed (and their signatures) actually came from the Debian project. That being said, you can try verifying the sha256 and you might catch "them" that way if they didn't think of that.
        12y ago
- andreaso 12y ago
  Well, if you want you can always manually download and verify the the packages. 1) Find list of applicable binary packages, for example by taking a look at https://packages.debian.org/source/wheezy/apt https://packages.debian.org/source/wheezy/apt 2) Download http://security.debian.org/dists/wheezy/updates/InRelease http://security.debian.org/dists/wheezy/updates/InRelease, and verify the gpg signature against the archive signing key, found in /etc/apt/trusted.gpg alt. in /etc/apt/trusted.gpg.d/*.gpg 3) Download http://security.debian.org/dists/wheezy/updates/main/binary-amd64/Packages.bz2 http://security.debian.org/dists/wheezy/updates/main/binary-..., and verify that its sha256 sum matches what you have in your previously downloaded InRelease file. 4 Inside the downloaded Packages.bz2 you'll find the relative paths as well as the sha256 sums of the packages you want to download. If nothing else this is a good exercise to see how the different pieces fit together.
- CGamesPlay 12y ago
  > does not properly invalidate unauthenticated data (CVE-2014-0488), performs incorrect verification of 304 replies (CVE-2014-0487), does not perform the checksum check when the Acquire::GzipIndexes option is used (CVE-2014-0489) and does not properly perform validation for binary packages downloaded by the apt-get download command (CVE-2014-0490). There are four specific scenarios that are vulnerable, and none of them appears to be the common scenario of updating packages. Details still sparse, but this seems like a minor security update.
- __david__ 12y ago
  Yeah, I was thinking exactly that as my hands typed `apt-get` from muscle-memory. In the end I decided to close my eyes and hope for the best.
JacobEdelman 12y ago
Anyone know how long these bugs have been around or if they have been exploited?
- api 12y ago
  The only secure computer is one that is off.
  - baldfat 12y ago
    The only secure computer is one that is not connected to the internet On/Off and some bad person is not physically present. I can fix off with wake on lan, press on button or just take your internal or external drives.
deleted 12y ago
[deleted]
morganvachon 12y ago
Seeing this almost makes me want to switch back to Slackware for good. Using a Debian based OS has made me lazy; I love the convenience of being able to apt-get whatever I want to install instead of downloading the source and building my own packages. But when you can't even trust the package manager on the most widespread* distro? Basically every single package on my system is now suspect (I did immediately upgrade apt but any damage is already done). *Speaking in terms of the number of derivatives that also use apt
- marcosdumay 12y ago
  How did you trust those sites you downloaded the sources from when you used Slackware?
  - morganvachon 12y ago
    Because it's the software author's site? I don't know how much more trust you could get, beyond only installing the software you write yourself.
    - eloisius 12y ago
      I think what grandparent means is: did you verify the SSL cert properly, verify the digest of the source code you downloaded to ensure it's authentic, etc…
      - morganvachon 12y ago
        Well, the thing is, I can do all that by getting the source myself directly from the author. Trusting the apt package maintainer to do that places trust in a third party, and beyond that, it's now obvious that apt for who knows how long, was not trustworthy. Again, I fail to see how getting the source directly from the author and verifying the integrity of the source package is less secure than getting it from third-parties in binary form?
        12y ago
0x0 12y ago
Is there an easy way to re-validate that previously installed .debs haven't been modified? Perhaps a script to at least check all the debs in the local apt archive cache? Also, does it really affect regular apt-get upgrades? "apt-get download" isn't a common way to run apt.
- pwnna 12y ago
  No, because your attacker could just modify that script, if there is an attacker. You can write a script yourself, and run it independently of apt, though.
- VLM 12y ago
  Reading your post literally, you're asking how what amounts to mirror operators ensure their mirror is clean, and that's a long story, especially WRT proxies like approx the apt specific proxy not just "real mirrors". If you're asking more about verifying the files on your install, assuming you trust debsums and its data not to be powned then you'd run debsums -c or whatever. Of course a real attacker would have their highest priority to mess with debsums and its data, hmm. Also debsums is quite slow and resource intensive, so pausing for 10 minutes doesn't mean its crashed or infinite looped, it just means its doing its thing. Finally if you run vanilla and never compile and overwrite your own copy of "whatever" then debsums will work, but if for example you installed debian's apache and then compiled your own apache and overwrote the debian apache binaries (why?), all debsums is going to know is your apache isn't standard debian apache so that doesn't necessarily prove your powned or un powned, it just proves you're not running Debian's apache binary. Google debsums, and this link will probably help https://packages.debian.org/sid/debsums https://packages.debian.org/sid/debsums Whatever you do, don't run "debsums -e" and freak out. At least not without reading the manpage and thinking about it a bit. OK debsums, thanks for letting me know someone modified /etc/ntp.conf, but I think that was me seeing as we have three GPS clocks on the LAN I feel no need to panic. It is an interesting command to use to see how modified a machine's install is. Oh I see you're running stock /etc/detault/ssh and no modifications at all to /etc/sysctl.conf, how interesting.
brockers 12y ago
Honestly, I wonder how many people here are going to worry about apt file signature verification while simultaneously running "bundle install" with a gemfile containing 50 sources including random github HEADs.
- squidmccactus 12y ago
  Go has github integration. Should I be worried.
- TheCraiggers 12y ago
  Well, the major difference being that apt is typically run as superuser, where I would presume you're not using sudo with bundle install. Unless there is an escalation exploit, worst case is that the code trashes your user's home folder. Still, a valid point for the vast majority of other package managers, including apt. At some point, you have to trust somebody though.
  - 0x0 12y ago
    But in almost all cases, the juicy data is in the user account. That's more important than leaking or deleting /bin/ls. :)
    - swartkrans 12y ago
      Yes if anyone ever got access to my user on my local dev machine, the gig is up. Although we keep production sensitive stuff gpg encrypted and require a password to decrypt, but there is so much information and data in my user home, you don't need super user access to cause damage.
      - AceJohnny2 12y ago
        Indeed, and I hadn't thought properly about it until XKCD, as often, shone a bright light on the nonsense that is root password paranoia: http://xkcd.com/1200/ http://xkcd.com/1200/ Which leads me to better respect what Ubuntu was doing with the Yama ptrace scope limiting (which prevents you from debugging a running process even if you're the same user, unless you change a /proc/sys var), and why the Weyland developers are wringing their hands on how to properly handle graphical app communication privileges (because currently, X11 allows any process to view any other process's display and events, including keyboard input)
squidmccactus 12y ago
Which distributions are effected by this bug?
sauere 12y ago
That feel when you see a Debian Security Advisory on the top of HN. Common guys, don't scare me to death. It thought this was going to be heartbleed all over again.
- deleted 12y ago
  [deleted]

ayrx 12y ago

So... Debian users will need to grab security fixes for `apt-get` using... `apt-get`?

yebyen 12y ago
I was going to say "you should be OK as long as you ..." But it seems like the CVEs are unavailable, I'm getting 502 Proxy Errors. It seems like four separate attack vectors are addressed in this update. This all is kind of surprising.
- handsomeransoms 12y ago
  Yeah, I'm having a hard time finding details on the vulnerabilities. A lot of the links in the advisories are broken, and the descriptions on the Mitre CVE pages seem to be awaiting update. Anybody know how to find better descriptions of these bugs, or the patches that fixed them?
  - pja 12y ago
    Here's the relevant changeset in the Debian apt git repo browser: http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=ca7fd76c2f30c100dcf1c12e717ce397cccd690b http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=ca7fd7...
  - VLM 12y ago
    I'm having trouble thinking of a realistic exploit for the first. The second would seem to require not using signing keys which most people have been using for a long time AND the people that are using signing keys (almost everyone) not complaining about bad stuff being substituted in AND the mirror/repo ops not noticing. The third isn't enabled by default and probably doesn't apply to many people. The fourth only applies to people who download and build from source which other than researchers and devs is pretty much no one and is another one of those that relies on everybody not paying attention. (edited to emphasize that the above isn't some kind of formal pronouncement of The Truth, but it is the logic I used when deciding how to prioritize this situation, which ended up with a conclusion of "not very important, not at all". Your situation not being identical to mine will almost certainly result in a somewhat different conclusion, much as my conclusion would be different if I were in your situation instead of mine.) http://www.ubuntu.com/usn/usn-2348-1/ http://www.ubuntu.com/usn/usn-2348-1/ It was discovered that APT did not re-verify downloaded files when the If-Modified-Since wasn't met. (CVE-2014-0487) It was discovered that APT did not invalidate repository data when it switched from an unauthenticated to an authenticated state. (CVE-2014-0488) It was discovered that the APT Acquire::GzipIndexes option caused APT to skip checksum validation. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS, and was not enabled by default. (CVE-2014-0489) It was discovered that APT did not correctly validate signatures when downloading source packages using the download command. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2014-0490)
    - edwintorok 12y ago
      How do you download source packages using the 'download' command? The debian advisory and manpage says that 'download' gives you the binary package, there's another 'apt-get source' command for the source package...
      - agwa 12y ago
        The Ubuntu advisory says "source packages" for some reason. I think it's a typo but it doesn't change the analysis - most people don't use 'apt-get download' to install packages.
        mdeslaur 12y ago
        Yes, that was a typo. Thanks for spotting it, I have updated the advisory: http://www.ubuntu.com/usn/usn-2348-1/ http://www.ubuntu.com/usn/usn-2348-1/
        edwintorok 12y ago
        you're right about that I didn't even know that 'apt-get download' existed, closest I ever used was 'apt-get source' :)
        agwa 12y ago
        'apt-get download' is a relatively recent addition.
    - agwa 12y ago
      I concur with your analysis of 2-4. Edit: Regarding #1(If-Modified-Since), the vulnerability is that if a hash in the Release file changes, but the file being referred to by the Release file gets served with a 304 response, apt will ignore the updated file and continue to use the old version of the file. even though the old version of the file doesn't match the new hash. An attacker could exploit this to prevent a system from receiving updates, though thankfully it doesn't seem to be possible to exploit this to cause apt to trust an arbitrary package. Original incorrect speculation below: Regarding #1 (If-Modified-Since), I'm wondering if perhaps their HTTP client incorrectly accepts a response body with a 304 response (contrary to the HTTP spec)? In that case a malicious server could deliver a file that's blindly trusted as long as it has a status of 304. (This is pure speculation, but I can't think of any other reason this would be a big deal.)
pja 12y ago
Slight chicken and egg problem there, agreed. You can check the package signatures for the downloaded debs in /var/cache/apt/archives by following the links for your architecture at the bottom of https://packages.debian.org/wheezy/apt https://packages.debian.org/wheezy/apt (You might need to check the rest of the apt-related debs as well. Just replace apt in the URL with the relevant package name and follow the links at the bottom to get the package hashes. If you're tracking sid instead of wheezy then just replace the distribution name in the URL.)
seren 12y ago
if 'libapt' is not the root cause and if it already is installed on your system , you can probably update safely using `aptitude update`.
- pbhjpbhj 12y ago
  libapt has also been updated and the changelog (accessed via aptitude) is the same as for apt itself. Interestingly both are given "urgency=low" ratings; at least 3 other updates have been medium urgency this year. Edit: sorry should have said on Ubuntu; I've got libapt-inst1.5:amd64 (1.0.1ubuntu2.3) from trusty/main.
  - mdeslaur 12y ago
    The urgency tag isn't used in Ubuntu, only in Debian.
spain 12y ago
Correct me if I'm wrong, but can't you just download the packages from https://packages.debian.org/wheezy/apt https://packages.debian.org/wheezy/apt and install them manually using dpkg?
- pja 12y ago
  Yes, you can definitely do that.
- cnlwsu 12y ago
  yeah, can be a pain to get the right dependancies in right order etc though. In this case probably easy enough
- yebyen 12y ago
  If you know how to verify the signatures properly, that would work. I'm thinking if you don't know that, and if you're willing to do what you just described, you probably don't really care about these CVEs anyway.
  - pwnna 12y ago
    Can't you also just verify the sha256 from debian's site? I wrote a script here: https://gist.github.com/shuhaowu/286e6681d6faa473ebb0 https://gist.github.com/shuhaowu/286e6681d6faa473ebb0
    - yebyen 12y ago
      sha256 doesn't provide any web-of-trust; if your download is compromised, the sha-sums that you download to verify them could also be compromised in the same way. If the crypto signatures are verified and your installed keyring is genuine (came from a genuine installation media), then you know that the packages you installed (and their signatures) actually came from the Debian project. That being said, you can try verifying the sha256 and you might catch "them" that way if they didn't think of that.
      - 12y ago
andreaso 12y ago
Well, if you want you can always manually download and verify the the packages. 1) Find list of applicable binary packages, for example by taking a look at https://packages.debian.org/source/wheezy/apt https://packages.debian.org/source/wheezy/apt 2) Download http://security.debian.org/dists/wheezy/updates/InRelease http://security.debian.org/dists/wheezy/updates/InRelease, and verify the gpg signature against the archive signing key, found in /etc/apt/trusted.gpg alt. in /etc/apt/trusted.gpg.d/*.gpg 3) Download http://security.debian.org/dists/wheezy/updates/main/binary-amd64/Packages.bz2 http://security.debian.org/dists/wheezy/updates/main/binary-..., and verify that its sha256 sum matches what you have in your previously downloaded InRelease file. 4 Inside the downloaded Packages.bz2 you'll find the relative paths as well as the sha256 sums of the packages you want to download. If nothing else this is a good exercise to see how the different pieces fit together.
CGamesPlay 12y ago
> does not properly invalidate unauthenticated data (CVE-2014-0488), performs incorrect verification of 304 replies (CVE-2014-0487), does not perform the checksum check when the Acquire::GzipIndexes option is used (CVE-2014-0489) and does not properly perform validation for binary packages downloaded by the apt-get download command (CVE-2014-0490). There are four specific scenarios that are vulnerable, and none of them appears to be the common scenario of updating packages. Details still sparse, but this seems like a minor security update.
__david__ 12y ago
Yeah, I was thinking exactly that as my hands typed `apt-get` from muscle-memory. In the end I decided to close my eyes and hope for the best.

JacobEdelman 12y ago

Anyone know how long these bugs have been around or if they have been exploited?

api 12y ago
The only secure computer is one that is off.
- baldfat 12y ago
  The only secure computer is one that is not connected to the internet On/Off and some bad person is not physically present. I can fix off with wake on lan, press on button or just take your internal or external drives.

deleted 12y ago

[deleted]

morganvachon 12y ago

Seeing this almost makes me want to switch back to Slackware for good. Using a Debian based OS has made me lazy; I love the convenience of being able to apt-get whatever I want to install instead of downloading the source and building my own packages. But when you can't even trust the package manager on the most widespread* distro? Basically every single package on my system is now suspect (I did immediately upgrade apt but any damage is already done). *Speaking in terms of the number of derivatives that also use apt

marcosdumay 12y ago
How did you trust those sites you downloaded the sources from when you used Slackware?
- morganvachon 12y ago
  Because it's the software author's site? I don't know how much more trust you could get, beyond only installing the software you write yourself.
  - eloisius 12y ago
    I think what grandparent means is: did you verify the SSL cert properly, verify the digest of the source code you downloaded to ensure it's authentic, etc…
    - morganvachon 12y ago
      Well, the thing is, I can do all that by getting the source myself directly from the author. Trusting the apt package maintainer to do that places trust in a third party, and beyond that, it's now obvious that apt for who knows how long, was not trustworthy. Again, I fail to see how getting the source directly from the author and verifying the integrity of the source package is less secure than getting it from third-parties in binary form?
      - 12y ago

0x0 12y ago

Is there an easy way to re-validate that previously installed .debs haven't been modified? Perhaps a script to at least check all the debs in the local apt archive cache? Also, does it really affect regular apt-get upgrades? "apt-get download" isn't a common way to run apt.

pwnna 12y ago
No, because your attacker could just modify that script, if there is an attacker. You can write a script yourself, and run it independently of apt, though.
VLM 12y ago
Reading your post literally, you're asking how what amounts to mirror operators ensure their mirror is clean, and that's a long story, especially WRT proxies like approx the apt specific proxy not just "real mirrors". If you're asking more about verifying the files on your install, assuming you trust debsums and its data not to be powned then you'd run debsums -c or whatever. Of course a real attacker would have their highest priority to mess with debsums and its data, hmm. Also debsums is quite slow and resource intensive, so pausing for 10 minutes doesn't mean its crashed or infinite looped, it just means its doing its thing. Finally if you run vanilla and never compile and overwrite your own copy of "whatever" then debsums will work, but if for example you installed debian's apache and then compiled your own apache and overwrote the debian apache binaries (why?), all debsums is going to know is your apache isn't standard debian apache so that doesn't necessarily prove your powned or un powned, it just proves you're not running Debian's apache binary. Google debsums, and this link will probably help https://packages.debian.org/sid/debsums https://packages.debian.org/sid/debsums Whatever you do, don't run "debsums -e" and freak out. At least not without reading the manpage and thinking about it a bit. OK debsums, thanks for letting me know someone modified /etc/ntp.conf, but I think that was me seeing as we have three GPS clocks on the LAN I feel no need to panic. It is an interesting command to use to see how modified a machine's install is. Oh I see you're running stock /etc/detault/ssh and no modifications at all to /etc/sysctl.conf, how interesting.

brockers 12y ago

Honestly, I wonder how many people here are going to worry about apt file signature verification while simultaneously running "bundle install" with a gemfile containing 50 sources including random github HEADs.

squidmccactus 12y ago
Go has github integration. Should I be worried.
TheCraiggers 12y ago
Well, the major difference being that apt is typically run as superuser, where I would presume you're not using sudo with bundle install. Unless there is an escalation exploit, worst case is that the code trashes your user's home folder. Still, a valid point for the vast majority of other package managers, including apt. At some point, you have to trust somebody though.
- 0x0 12y ago
  But in almost all cases, the juicy data is in the user account. That's more important than leaking or deleting /bin/ls. :)
  - swartkrans 12y ago
    Yes if anyone ever got access to my user on my local dev machine, the gig is up. Although we keep production sensitive stuff gpg encrypted and require a password to decrypt, but there is so much information and data in my user home, you don't need super user access to cause damage.
    - AceJohnny2 12y ago
      Indeed, and I hadn't thought properly about it until XKCD, as often, shone a bright light on the nonsense that is root password paranoia: http://xkcd.com/1200/ http://xkcd.com/1200/ Which leads me to better respect what Ubuntu was doing with the Yama ptrace scope limiting (which prevents you from debugging a running process even if you're the same user, unless you change a /proc/sys var), and why the Weyland developers are wringing their hands on how to properly handle graphical app communication privileges (because currently, X11 allows any process to view any other process's display and events, including keyboard input)

squidmccactus 12y ago

Which distributions are effected by this bug?

sauere 12y ago

That feel when you see a Debian Security Advisory on the top of HN. Common guys, don't scare me to death. It thought this was going to be heartbleed all over again.

deleted 12y ago
[deleted]