Re: RFC / Call for testing: ghostscript
On Wed, Jan 30, 2019 at 03:02:53PM +0100, Markus Koschany wrote: > The truth is the -dSafer option gives a false sense of security even in > the latest release and we will probably continue to see more of those > issues. Obviously, any deployment which processes documents should use additional hardening, e.g. running ghostscript in firejail, but we still need to fix these. > The version in Jessie is more than seven years old already, so > you have to carefully weigh the usefulness of backporting the latest > stable release and the risk of breaking reverse-dependencies. The > targeted approach worked well so far and all known vulnerabilities were > addressed. The Jessie version is not any less secure than the version in > Stretch and the codebase is very different. No systematic triage has happened for older GS versions and given the rate of findings by taviso there're bound to be issues which were fixed in the past, but didn't get a CVE assigned. We need to look at the big picture here. > The point was you had to deal with regressions but the original version > in Stretch was much more recent than the one in Jessie. You cannot rule > out this will be the only functional change for Jessie users. The API hasn't changed between jessie and the current 9.26 versions in stretch, I don't expect any real issues. Ubuntu also rebased 14.04/trusty to 9.26. Cheers, Moritz
Re: RFC / Call for testing: ghostscript
[No need to CC me, I am subscribed] Am 30.01.19 um 14:29 schrieb Moritz Mühlenhoff: > On Wed, Jan 30, 2019 at 01:24:40PM +0100, Markus Koschany wrote: >> Hi, >> >> Am 30.01.19 um 13:07 schrieb Emilio Pozuelo Monfort: >> [...] >>> I would appreciate some testing and/or feedback. >> >> I have done most of the backporting work for the previous >> vulnerabilities of Ghostscript. I don't recommend to backport the stable >> version to Jessie at the moment but rather to continue to address those >> issues with targeted fixes. > > I disagree, rebasing to the latest release is the only sensible approach > (and I would have advised it already for the previous DLAs). While a number > of CVEs have been assigned over time, I strongly doubt they're exhaustive > and there were cases where CVE IDs had been assigned for bugs which had been > fixed as regular bugs and only got a CVE ID when taviso diagnosed the security > impact in hindsight. There's a reason DSA-4336-1 rebased to 9.25 after > DSA-4294-1 had already shipped a significant number of backports. The truth is the -dSafer option gives a false sense of security even in the latest release and we will probably continue to see more of those issues. The version in Jessie is more than seven years old already, so you have to carefully weigh the usefulness of backporting the latest stable release and the risk of breaking reverse-dependencies. The targeted approach worked well so far and all known vulnerabilities were addressed. The Jessie version is not any less secure than the version in Stretch and the codebase is very different. >> There is a high risk that >> reverse-dependencies will be negatively affected and there were also >> regressions in Stretch the security team had to deal with. > > The regression fixed in DSA-4346-2 was a functional change within the newer > upstream release (i.e. it also affected sid) and it's fixed now, so that's > moot for jessie. The point was you had to deal with regressions but the original version in Stretch was much more recent than the one in Jessie. You cannot rule out this will be the only functional change for Jessie users. If Emilio wants to go this route than he should be prepared to handle those regressions too. Markus signature.asc Description: OpenPGP digital signature
Re: RFC / Call for testing: ghostscript
On Wed, Jan 30, 2019 at 01:24:40PM +0100, Markus Koschany wrote: > Hi, > > Am 30.01.19 um 13:07 schrieb Emilio Pozuelo Monfort: > [...] > > I would appreciate some testing and/or feedback. > > I have done most of the backporting work for the previous > vulnerabilities of Ghostscript. I don't recommend to backport the stable > version to Jessie at the moment but rather to continue to address those > issues with targeted fixes. I disagree, rebasing to the latest release is the only sensible approach (and I would have advised it already for the previous DLAs). While a number of CVEs have been assigned over time, I strongly doubt they're exhaustive and there were cases where CVE IDs had been assigned for bugs which had been fixed as regular bugs and only got a CVE ID when taviso diagnosed the security impact in hindsight. There's a reason DSA-4336-1 rebased to 9.25 after DSA-4294-1 had already shipped a significant number of backports. > There is a high risk that > reverse-dependencies will be negatively affected and there were also > regressions in Stretch the security team had to deal with. The regression fixed in DSA-4346-2 was a functional change within the newer upstream release (i.e. it also affected sid) and it's fixed now, so that's moot for jessie. > The whole sandbox concept of ghostscript appears very fragile and even > upstream seems to struggle to close all the loopholes. We should rather > disable ghostscript handled formats in graphicsmagick and imagemagick by > default as I have previously suggested and let users handle it manually. That is a solid plan on itself, but does not help for all legitimate cases where ghostscript is invoked on untrusted content without any involvement of the magicks. To properly fix that (to the extent of currently known vulnerabilities) this still needs a rebase to 9.26a. > [1] We could also invest the time to fix this in unstable first and > learn from the result. [2] Ack, it would be nice if this could land in time for buster. Cheers, Moritz
Re: RFC / Call for testing: ghostscript
Hi, Am 30.01.19 um 13:07 schrieb Emilio Pozuelo Monfort: [...] > I would appreciate some testing and/or feedback. I have done most of the backporting work for the previous vulnerabilities of Ghostscript. I don't recommend to backport the stable version to Jessie at the moment but rather to continue to address those issues with targeted fixes. There is a high risk that reverse-dependencies will be negatively affected and there were also regressions in Stretch the security team had to deal with. In case of ghostscript a complete backport from stable should be the last resort. The whole sandbox concept of ghostscript appears very fragile and even upstream seems to struggle to close all the loopholes. We should rather disable ghostscript handled formats in graphicsmagick and imagemagick by default as I have previously suggested and let users handle it manually. [1] We could also invest the time to fix this in unstable first and learn from the result. [2] Regards, Markus [1] https://lists.debian.org/debian-lts/2018/10/msg00019.html [2] https://bugs.debian.org/907336 signature.asc Description: OpenPGP digital signature
