January 2018 report: LTS
I have already published a yearly report which covers all of 2017 but also some of my January 2018 work, so I'll try to keep this short.
Debian Long Term Support (LTS)
This is my monthly Debian LTS report. I was happy to switch to the new Git repository for the security tracker this month. It feels like some operations (namely pull / push) are a little slower, but others, like commits or log inspection, are much faster. So I think it is a net win.
jQuery
I did some work on trying to cleanup a situation with the jQuery package, which I explained in more details in a long post. It turns out there are multiple databases out there that track security issues in web development environemnts (like Javascript, Ruby or Python) but do not follow the normal CVE tracking system. This means that Debian had a few vulnerabilities in its jQuery packages that were not tracked by the security team, in particular three that were only on Snyk.io (CVE-2012-6708, CVE-2015-9251 and CVE-2016-10707). The resulting discussion was interesting and is worth reading in full.
A more worrying aspect of the problem is that this problem is not limited to flashy new web frameworks. Ben Hutchings estimated that almost half of the Linux kernel vulnerabilities are not tracked by CVE. It seems the concensus is that we want to try to follow the CVE process, and Mitre has been helpful in distributing this by letting other entities, called CVE Numbering Authorities or CNA, issue their own CVEs. After contacting Snyk, it turns out that they have started the process of becoming a CNA and are trying to get this part of their workflow, so that's a good sign.
LTS meta-work
I've done some documentation and architecture work on the LTS project itself, mostly around updating the wiki with current practices.
OpenSSH DLA
I've done a quick security update of OpenSSH for LTS, which resulted
in DLA-1257-1. Unfortunately, after a discussion with the
security researcher that published that CVE, it turned out that this
was only a "self-DOS", i.e. that the NEWKEYS attack would only make
the SSH client terminate its own connection, and therefore not impact
the rest of the server. One has to wonder, in that case, why this was
issue a CVE at all: presumably the vulnerability could be leveraged
somehow, but I did not look deeply enough into it to figure that out.
Hopefully the patch won't introduce a regression: I tested this summarily and it didn't seem to cause issue at first glance.
Hardlinks attacks
An interesting attack (CVE-2017-18078) was discovered against
systemd where the "tmpfiles" feature could be abused to bypass
filesystem access restrictions through hardlinks. The trick is that
the attack is possible only if kernel hardening (specifically
fs.protected_hardlinks) is turned off. That feature is available in
the Linux kernel since the 3.6 release, but was actually turned off
by default in 3.7. In the commit message, Linus Torvalds
explained the change was breaking some userland applications, which is
a huge taboo in Linux, and recommended that distros configure this at
boot instead. Debian took the reverse approach and Hutchings issued a
patch which reverts the default to the more secure default. But
this means users of custom kernels are still vulnerable to this issue.
But, more importantly, this affects more than systemd. The
vulnerability also happens when using plain old chown with hardening
turned off, when running a simple command like this:
chown -R non-root /path/owned/by/non-root
I didn't realize this, but hardlinks share permissions: if you change
permissions on file a that's hardlinked to file b, both files have
the new permissions. This is especially nasty if users can hardlink to
critical files like /etc/password or suid binaries, which is why the
hardening was introduced in the first place.
In Debian, this is especially an issue in maintainer scripts, which
often call chown -R on arbitrary, non-root directories. Daniel Kahn
Gillmor had reported this to the Debian security team all the way back
in 2011, but it didn't get traction back then. He now opened Debian bug #889066 to at least enable a warning in lintian and an issue was also
opened on colord Debian bug #889060, as an example, but many more
packages are vulnerable. Again, this is only if hardening is somewhat
turned off.
Normally, systemd is supposed to turn that hardening on, which should
protect custom kernels, but this was turned off in
Debian. Anyways, Debian still supports non-systemd init systems
(although those users mostly probably all migrated to Devuan) so
the fix wouldn't be complete. I have therefore filed Debian bug #889098 against procps (which owns /etc/sysctl.conf and related
files) to try and fix the issue more broadly there.
And to be fair, this was very explicitly mentioned in the jessie release notes so those people without the protection kind of get what they desserve here...
p7zip
Lastly, I did a fairly trivial update of the p7zip package, which resulted in DLA-1268-1. The patch was sent upstream and went through a few iterations, including coordination with the security researcher.
Unfortunately, the latter wasn't willing to share the proof of concept (PoC) so that we could test the patch. We are therefore trusting the researcher that the fix works, which is too bad because they do not trust us with the PoC...
Other free software work
I probably did more stuff in January that wasn't documented in the
previous report. But I don't know if it's worth my time going through
all this. Expect a report in February instead! 
Have happy new year and all that stuff.
Unfortunately the release notes only mentioned the symlink restriction and not the hard link restriction, and didn't mention sysctl.conf.
What's more, this was done one release too late! Although these restrictions were implemented upstream in Linux 3.6, they are included in the linux package in wheezy.