Re: amd64-microcode, test
Thanks Emilio and Salvatore for very valuable comments! I think then, that it would be more proper way to upload the lower upstream version 3.20181128.1 into the Jessie and Stretch to escape higher versions on older releases. This 3.20181128.1 version also fixes CVE-2017-5715 and is now the current one in Buster. Also it seems to be reliable on AMD EPYC 7542, which showed regression previously [1]. Thus I am asking for testing of newly updated package for Jessie [2], if somebody has an access to the hardware with AMD processors. If no negative feedback will come within the next few days, I will upload it into archive on Saturday evening. Debdiff is attached. [1] https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1853614 [2] https://people.debian.org/~gladk/amd64-microcode_jessie/ Best regards Anton On 3/11/20 9:37 PM, Emilio Pozuelo Monfort wrote: > On 11/03/2020 21:06, Salvatore Bonaccorso wrote: >> Hi, >> >> A smaller comment on the update: >> >> On Wed, Mar 11, 2020 at 08:19:11PM +0100, Anton Gladky wrote: >>> After discussion with the maintainer I decided to backport the latest >>> upstream version, available in Debian (3.20191218.1). Prepared package >>> is available here [1]. Debdiff is attached. >> [...] >>> [1] https://people.debian.org/~gladk/amd64-microcode/ >> >> If this is 3.20191218.1 upload backported/rebuild for jessie then >> please use 3.20191218.1~deb8u1, rather than 3.20191218.1+deb8u1, which >> will not correctly sort before 3.20191218.1 otherwise. > > This should also be coordinated with buster and stretch point updates, so that > we avoid having a higher version in jessie. > > Cheers, > Emilio > diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.default amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.default --- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.default 1970-01-01 01:00:00.0 +0100 +++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.default 2018-12-15 03:43:55.0 +0100 @@ -0,0 +1,13 @@ +# Configuration script for amd64-microcode version 3 + +# +# initramfs helper +# + +# +# Set this to "no" to disable automatic microcode updates on boot; +# Set this to "early" to always install microcode updates to the early initramfs +# Set this to "auto" to autodetect mode for current system (default); +# +#AMD64UCODE_INITRAMFS=auto + diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.dirs amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.dirs --- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.dirs 1970-01-01 01:00:00.0 +0100 +++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.dirs 2018-12-15 03:43:55.0 +0100 @@ -0,0 +1,3 @@ +etc/default +etc/modprobe.d +lib/firmware/amd-ucode diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.docs amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.docs --- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.docs 1970-01-01 01:00:00.0 +0100 +++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.docs 2018-12-15 03:43:55.0 +0100 @@ -0,0 +1,3 @@ +README +microcode_amd.bin.README +microcode_amd_fam*.README diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.install amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.install --- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.install 1970-01-01 01:00:00.0 +0100 +++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.install 2018-12-15 03:43:55.0 +0100 @@ -0,0 +1,2 @@ +microcode_amd.bin /lib/firmware/amd-ucode +microcode_amd_fam*.bin /lib/firmware/amd-ucode diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.modprobe-blacklist amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.modprobe-blacklist --- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.modprobe-blacklist 1970-01-01 01:00:00.0 +0100 +++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.modprobe-blacklist 2018-12-15 03:43:55.0 +0100 @@ -0,0 +1,3 @@ +# The microcode module attempts to apply a microcode update when +# it autoloads. This is not always safe, so we block it by default. +blacklist microcode diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postinst amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.postinst --- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postinst 1970-01-01 01:00:00.0 +0100 +++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.postinst 2018-12-15 03:43:55.0 +0100 @@ -0,0 +1,46 @@ +#!/bin/sh +# postinst script for amd64-microcode +# +# see: dh_installdeb(1) + +set -e + +# summary of how this script can be called: +#* `configure' +#* `abort-upgrade' +#* `abort-remove' `in-favour' +# +#* `abort-remove' +#* `abort-deco
Re: phppgadmin / CVE-2019-10784
Ola Lundqvist writes: > I have ideas on how we can reduce the attack possibilities but I cannot > find any perfect solution to this. What about setting samesite=Lax in the session Cookie? This should solve all problems for POST requests. Are there any vulnerable GET requests? Additionally this is already the default for Chrome (I don't think Firefox has done this yet though). https://web.dev/samesite-cookies-explained/ I posted this suggestion upstream also, but got no response - yet. https://github.com/phppgadmin/phppgadmin/issues/94#issuecomment-597464834 Only problem is older browsers won't be protected, I am not sure this is a big issue however. I imagine setting the samesite value will be a lot less invasive then some of the other solutions being discussed here. The other problem might be implementing this. I see PHP has a session.cookie_samesite option but this was only implemented in PHP >= 7.3 https://www.php.net/manual/en/session.configuration.php -- Brian May
Re: Issues regarding ruby-rack/CVE-2019-16782
The comment about that one is safe for anyone to have and the private cannot be leaked is really strange. It is trivial to generate the private one, just as you write. // Ola On Tue, 10 Mar 2020 at 07:38, Brian May wrote: > Ola Lundqvist writes: > > > I think the attacker needs to be very close, or at least on a connection > to > > the server with a very predictable timing making a live server exploit > > difficult from a distance. Potentially possible. > > Yes, very likely. Unless the database is loaded, but that too could be > another variable that makes this attack difficult. > > > This is a general problem for most kind of services and I do not think it > > is limited to ruby-rack. It just happen to be so that we have a specific > > CVE for ruby-rack. Others may have exactly the same issue. > > Agreed. > > > The solution to look up the hash of the session id makes sense. It makes > > things much harder to exploit. > > > > The best solution as I see it is to do one the following: > > > > alternative 1: > > At upgrade change all database session keys to the hash(key) and then > only > > lookup using the hash of the session id key. > > There is no need to change the interface at all as I can see it. > > This would be my preference. As I have mentioned before, upstream were > concerned this might break applications. > > The details given here - > https://github.com/rack/rack/issues/1432#issuecomment-571688819 - don't > entirely make sense to me. e.g. "The private id could be leaked" - if > the public id is leaked, then it is easy to generate the private id > anyway. > > > alternative 2: > > No change at upgrade. At lookup look for the hash(key) and if that fails > > look for the key. To improve the security we can introduce a random delay > > between 0 and ... well the time a lookup take worst case. > > Still no reason to change the interface as I see it. > > Yes, this is what upstream did, apart from the "not change the > interface" or "introduce a random delay". > > > alternative 3: > > Do as upstream. The problem is that upstream introduced an API change in > a > > non-backwards compatible way. This works for unstable, but I do not think > > it is preferred for oldstable, oldoldstable or stable. > > > > Which one to choose. I think alternative 1 is the most secure option but > > the upgrade may be complicated and is a little fault prone. I think > > alternative 2 is good enough, especially with some random delay. > > Like I said, I am struggling to understand why upstream feels they need > to keep track of two separate ids, or why not just hash the key before > each database lookup. > > I am finding it hard to visualise an application that would use the > session id in such a way that it would break if we hash it before > looking up the database. > > I am not familiar with Ruby coding standards, Maybe existing Ruby code > can do "interesting things" such as direct lookups in the session database > using the session key? > > Also I noticed - and thought interesting - that storing sessions in the > database was considered using rails (not rack being discussed here) was > deprecated in 2012) > > > http://blog.remarkablelabs.com/2012/12/activerecord-sessionstore-gem-extraction-rails-4-countdown-to-2013 > -- > Brian May > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: phppgadmin / CVE-2019-10784
Hi I do not see how SameSite attribute would help in this case. Or how do you mean that it would protect against this? // Ola On Thu, 12 Mar 2020 at 22:02, Brian May wrote: > Ola Lundqvist writes: > > > I have ideas on how we can reduce the attack possibilities but I cannot > > find any perfect solution to this. > > What about setting samesite=Lax in the session Cookie? This should solve > all problems for POST requests. Are there any vulnerable GET requests? > Additionally this is already the default for Chrome (I don't think > Firefox has done this yet though). > > https://web.dev/samesite-cookies-explained/ > > I posted this suggestion upstream also, but got no response - yet. > https://github.com/phppgadmin/phppgadmin/issues/94#issuecomment-597464834 > > Only problem is older browsers won't be protected, I am not sure this is > a big issue however. > > I imagine setting the samesite value will be a lot less invasive then > some of the other solutions being discussed here. > > The other problem might be implementing this. I see PHP has a > session.cookie_samesite option but this was only implemented in PHP >= > 7.3 > > https://www.php.net/manual/en/session.configuration.php > -- > Brian May > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
