oss-sec mailing list archives
Re: Own on install. How grave it is?
From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 9 Jan 2018 11:33:48 -0700
One thing to keep in mind: most operating systems can have their install media updated, e.g. Windows slipstream where you make an install media with all available updates, or you can install updates without a network trivially (e.g. for RPM/DPKG based systems just have a USB key with a copy of the updates and install them). To say nothing of using orchestration tools that essentially can take care of it themselves, or generating master images that are up to date (containers/Docker are a good example here, you want to deploy up to date containers and then refresh the entire container for updates, not run yum update inside of it, cattle not pets and all that). Obviously things that don't support this add risk (e.g. you MUST connect to the internet to get updates), and if the update tools themselves have a problem, you have a major problem. On Tue, Jan 9, 2018 at 9:46 AM, Simon McVittie <smcv () debian org> wrote:
On Tue, 09 Jan 2018 at 08:37:08 -0700, Kurt Seifried wrote:Many OS installs/etc take a password during installI think Georgi was more concerned about the installation having a secure design, but an insecure (vulnerable) implementation appearing on the installation media due to either unfixed vulnerabilities, or vulnerabilities that were fixed elsewhere but not on the installation media? For instance, the Debian installer installs packages from the install media (CD, USB stick, whatever), then immediately updates them from the Internet if possible; but there's a chicken-and-egg problem here, because that update has to be done with whatever version of apt was on the media. If that version happens to suffer from a vulnerability that can be exploited at that time (such as https://security-tracker.debian.org/tracker/CVE-2016-1252 in apt itself, or a vulnerability in the http or signature verification code that it uses) then there's an opportunity for attack. The same is true for the kernel and network-device firmware used to boot the installer. Debian mitigates this by releasing updated installation media at every point release (about 1 per 2 months for stable, somewhat slower for oldstable). I don't see any way to prevent that class of attack completely. Releasing updated installation media sooner would mitigate it, but preparing installation media is far from being a rapid process.On Tue, Jan 9, 2018 at 6:42 AM, Georgi Guninski <guninski () guninski com> wrote:Debian jessie (old stable) is vulnerable to malicious mirror attack.Assuming you're referring to CVE-2016-1252, whether this is true depends what you mean by jessie. Installs from older media (up to and including 8.6) will be vulnerable to CVE-2016-1252 during the first upgrade run, whereas installs from newer media (8.7 or newer, with the current version being 8.10) are not vulnerable. It's true that there was a window (in this case it happens to be 1 month) during which Debian offered an update for CVE-2016-1252, but the newest available installation media still suffered from it. smcv
-- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secalert () redhat com
Current thread:
- Own on install. How grave it is? Georgi Guninski (Jan 09)
- Re: Own on install. How grave it is? Kurt Seifried (Jan 09)
- Re: Own on install. How grave it is? Simon McVittie (Jan 09)
- Re: Own on install. How grave it is? Kurt Seifried (Jan 09)
- Re: Own on install. How grave it is? Simon McVittie (Jan 09)
- Re: Own on install. How grave it is? Michal Hrušecký (Jan 09)
- Re: Own on install. How grave it is? Kurt Seifried (Jan 09)