[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

(E)LTS report for October 2023

I've worked during October 2023 on the below listed packages, for
Freexian LTS/ELTS [1] 

Many thanks to Freexian and sponsors [2] for providing this opportunity!


firmware-nonfree - ELA-981-1 
  This was a contiunation of DLA-3596-1, which I've released in September,
  this time for ELTS (jessie and stretch). The work for ELTS was based
  on the package for buster, therefore appoligises for the repeation
  of my last month's report, continuing the trend I've set last month :)

  Following Intels security advisory INTEL-SA-00766 several firmware
  blobs for some of their Wifi/Bluetooth products have been updated to
  fix several CVEs.

  Firmwareblobs provide their own challenges, as obviously there is
  no source to inspect to verify things. and addtional the vendor is not
  very clear in their communication which would help identifying the
  correct firmware blob, so the only information available was that the
  problem is "Fixed upstream in linux-firmware/20230804".

  Looking at the repository I could identify a few commits that
  were touching Intel firmware files to extract the updates files,
  and to cherry-pick them into an updated buster firmware-nonfree
  package. Feedback from the package maintainers was that this normal
  and the only thing we can do, unfortunatly.

  Firmwareblobs provide their own challenge, (yes, I'm repeating
  myself:) It seems that the Intel blob <-> kernel interface is using
  a versioned ABI, and the kernels only can cater a certain range. That
  means, that *some* of the updated firmware files will not be loadable
  by buster's kernel, a thing that I only figured out _after_ I
  integrated the files already into the packaging and checked with the
  linux kernel sources. 
  I left them in in the hope that there are folks that will still
  benefit from them, however, I encourage people to verify their
  setup so that they know if they are still vulnerable. 

  Unfortunatly, this is all we can do when non-free binary blobs
  are involved.

nghttp2/stretch - ELA-984-1 (CVE-2023-44487)
  Arstechnica titled this CVE has been as "Biggest DDoSes of all time
  generated by protocol 0-day in HTTP/2" [0] and also the blog article
  from cloudfare [1] is an interesting read about this vulnerablity. As
  this vulnerablity is a flaw in the HTTP/2 protocol, many vendors are
  affected, so nghttp2.
  The backporting of the upstream patch was quite straight forward,
  and their extensive test suite helped a lot too, even one of their
  testcases misbehaved and needed debugging into it and was determined
  to be a false positive.
  However, a failing test case is always concerning I was looking for
  additional ways to test the fix. Fortunatly I've found a github
  repository claiming to be a detection tool for the vulnerabilty [2].
  Unfortunatly this is quite a stretch, as that tool only checks
  if the server support RST_STREAM and beside that obviously servers
  not supporting RST_STREAM (are there any?) it has no meaning at all
  whether the the server is vulnerable or not. 
  I've rewritten the script so that it can test if a server rate limit
  RST_STREAM, and so becames a test for the problem at hand. The script
  is here: https://paste.debian.net/1295129/ With that I could confirm
  that, without the patch, nghttp2 is suspectible to the attack, and
  with the patch it is no longer.
[0] https://arstechnica.com/security/2023/10/how-ddosers-used-the-http-2-protocol-to-deliver-attacks-of-unprecedented-size/
[1] https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
[2] https://github.com/bcdannyboy/CVE-2023-44487


freerdp2: (DLA-3606-1) - gnome-boxes (DLA-3607-1) - vinagre (DLA-3608-1)
  Started working on this package in September and continued in October,
  fixing this package caused a lot of effort. 
  The package had 60 CVE'S open, and only a few have spelled out the
  explicit patches that are required to fix them I first investigated
  if it is possible to pull in a new upstream version, for example
  As reported last month already, the reverse dependencies vinagre and
  gnome-boxes started to act up, e.g showing only black screens or
  becoming unstable and some research found that this is problems
  were with these programs, not with freerdp2, and patches could be
  found, applied and uploaded. (as DLA-3607 and DLA-3608)
  I've also tried 2.11.1 -- thanks to sunweaver for providing it quickly
  -- but this caused buster's remmina to occasinally crash, and without
  finding the reason for it, it was better to play it safe and stay at
  2.3.0, and backport the remaining issues. For that I've received a lot
  of help from upstream (thanks diget!), identifing the commits needed
  to fix several CVEs. Unfortunatly when finishing the package, I
  missed a few CVEs that where not fixed by 2.3.0 and not in the list
  from diget, and therefore there will be an subsequent upload later.
[1]  https://www.freexian.com/lts/
[2]  https://www.freexian.com/lts/debian/#sponsors


Attachment: signature.asc
Description: PGP signature

Reply to: