[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANO=Ty0aVUpdVJGer0XaoWyKJ97px6sycxms67MpXv2CVO7oDg@mail.gmail.com>
Date: Tue, 9 Jan 2018 11:33:48 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Cc: Georgi Guninski <guninski@...inski.com>
Subject: Re: Own on install. How grave it is?
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@...ian.org> wrote:
> On Tue, 09 Jan 2018 at 08:37:08 -0700, Kurt Seifried wrote:
>> Many OS installs/etc take a password during install
>
> I 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@...inski.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@...hat.com
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
