Dear Maintainer,

I emailed the following to debian-security and was advised to open a public bug for it.

Debian-installer will accept a preseed URL provided via a DHCP option, even when installed from CD-ROM. No authentication of this parameter can be performed, and the user is not prompted before it is accepted due to the nature of preseeding. Due to this, an attacker on the local network can spoof a DHCP responce pointing to their own preseed file, which can do all sorts of mischief (such as adding users or executing commands).

An example:

in dhcpd.conf:
  if substring(option vendor-class-identifier, 0, 3 = "d-i" { filename "http://192.168.1.1/preseed.txt" }
and in /var/www/preseed.txt:
  d-i preseed/early_command string reboot

which will send the client into a reboot loop.

I'm not sure of the best way to mitigate this, without annoying people who use this feature. Perhaps a kernel commandline arg to specifically enable preseed via DHCP is a good idea? I understand that one expected use case is for an administrator to specify an apt mirror via DHCP preseed, so that even users installing from their own CD/DVD will pick it up, which would break in this scenario.

So the actual problem is that the local network is compromised.

A good idea is getting the local network
to a state where it can be trusted to use DHCP at all.


Groeten
Geert Stappers
Who considered
control: tag -1 wontfix

Geert Stappers <stappers@stappers.nl> (2015-06-13):

I don't think handwaving and tagging wontfix is the right play here.

Mraw,
KiBi.

control: tag -1 mordac

Now tagging with 'mordac'. For those new to Mordac, get a
first impression at http://dilbert.com/strip/2007-11-16
And http://dilbert.com/search_results?terms=Mordac for a complete overview
of Mordac, the preventer of information services.



In other words:

How to cope with nonsense like "security is more important than usability"?


Further discussion should go to d-boot@l.d.o., Reply-To is set for it.


And ignoring this bugreport is also fine.
KiBi is right, it is code that matters.


Groeten
Geert Stappers

It's not nonsense.

Yes, if you boot off PXE, then it's fine if the network contains
preseeding data. After all, you booted off PXE, so either your network
is fine (and nothing to worry about) or it isn't (and then using a
preseeding file off the network isn't going to make matters much worse,
since you've already *booted* untrusted code).

But if you boot off CD-ROM or USB or some such? Then the situation is
much different. While I agree that having preseeding in that case can be
useful, I can also understand the POV that the system *defaulting* to
using such a preseed file is a bad idea.

Let's say you buy a new laptop, take it out of the packaging while on
the train home, pop in a USB stick with d-i on it, and boot. Somewhere
on the way home, your train waits in a train station for a few minutes,
during which time it picks up the wireless connection and does DHCP
there. Should it trust any preseeding data that it got from that
connection?

I don't think so, but currently this *does* happen.

insecure by nature - it's pointless to secure a PXE-booted system -
but I also think that it is reasonable for an end user, who does not
know or care about preseeding, to believe that installation is safe on
a hostile network, particularly because apt is so careful about
verifying signatures (albeit of data that crossed the entire
internet).

If, as Geert Stappers says, more users use this (reasonably obscure?)
feature than are concerned with the security implications of it, then
as an absolute minimum, adding a commandline arg to disable it would
allow security-minded users to install in hostile networks without
possibility of compromise.

I still feel that this is insufficient, though, because the average
end-user will end up having their system compromised (possibly by one
of the notoriously-insecure home internet gateways that seem to be
popular these days). It's my opinion that feature in question should
be disabled by default, and opt-in with a commandline argument. I've
written a simple patch to implement this (see below). It adds a dialog
that is shown only when a preseed URL is provided via DHCP, and is can
be suppressed (ie, restores the current behaviour of silently
accepting) with the kernel commandline
"preseed/accept_preseed_from_DHCP=true".

For anyone who feels similarly to me, I have built an install CD with
a patched d-i, which I intend to maintain as a fork of the original
d-i project. I have limited resources, however, so I've only built for
jessie on amd64 right now - I hope to add support for more versions
and architectures at some point in the future, but would appreciate
the help of someone more experienced with d-i (or even debian
development!) if possible. My blog post about it is at
https://strange.systems/debian-installer-insecurity .

My patch against 20150422+deb8u1 (please note: I've never submitted to
the Debian project before, so please let me know if I've done anything
wrong here):

diff -ur old/DEBIAN/postinst new/DEBIAN/postinst
--- old/DEBIAN/postinst 2014-09-24 06:16:34.000000000 +0100
+++ new/DEBIAN/postinst 2015-06-15 01:31:43.884000000 +0100
@@ -11,7 +11,13 @@

 dhcp_url=$(dhcp_preseed_url)
 if [ -n "$dhcp_url" ]; then
- preseed_location "$dhcp_url"
+ db_input critical preseed/accept_preseed_from_DHCP || true
+ db_go
+ db_get preseed/accept_preseed_from_DHCP
+ use_dhcp_url=$RET
+ if [ "$use_dhcp_url" == "true" ]; then
+ preseed_location "$dhcp_url"
+ fi
 fi
 preseed preseed/url
 preseed_command preseed/early_command
diff -ur old/DEBIAN/templates new/DEBIAN/templates
--- old/DEBIAN/templates 2014-09-24 06:16:33.000000000 +0100
+++ new/DEBIAN/templates 2015-06-15 01:24:27.396000000 +0100
@@ -1048,3 +1048,13 @@
 Default: d-i/jessie/./preseed.cfg
 Description: for internal use; can be preseeded
  Path added to local server to give the preseed root
+
+Template: preseed/accept_preseed_from_DHCP
+Type: boolean
+Default: false
+Description: Should we accept a preseed URL from a DHCP server?
+ Your DHCP server has provided extra commands or customisations to
+ debian-installer. It is possible that these commands were sent by
+ your network administrator; however, it is impossible to verify
+ this, or to ensure they have not been altered by an attacker who
+ already has access to your local network.
 Template: debian-installer/network-preseed/title

I've sent this mail to the bugtracker (in addition to the l.d.o. list)
since it contains a patch. I hope this is the correct behaviour.

(no need to CC me or debian-boot to answers as bug report answers
already go to debian-boot)

Quoting Aliz 'Randomdude' (randomdude@gmail.com):


This patch shouldn't be committed as is to the git repository. It
needs rewording in the debconf template, to avoid a few style
inconsistencies with the writing style of other D-I templates:

- drop the use of first person ("we")
- drop the use of "your"

The template is also not marked for translation ("_Description"
instead of "Description") even though it's clearly worded to be
interactive...

Ah, sorry. Thanks for letting me know.

Okay - my apologies for not reading the relevant "best packaging
practices" document first. Here's a revised patch:

diff -ur old/DEBIAN/postinst new/DEBIAN/postinst
--- old/DEBIAN/postinst 2014-09-24 06:16:34.000000000 +0100
+++ new/DEBIAN/postinst 2015-06-15 01:31:43.884000000 +0100
@@ -11,7 +11,13 @@

 dhcp_url=$(dhcp_preseed_url)
 if [ -n "$dhcp_url" ]; then
- preseed_location "$dhcp_url"
+ db_input critical preseed/accept_preseed_from_DHCP || true
+ db_go
+ db_get preseed/accept_preseed_from_DHCP
+ use_dhcp_url=$RET
+ if [ "$use_dhcp_url" == "true" ]; then
+ preseed_location "$dhcp_url"
+ fi
 fi
 preseed preseed/url
 preseed_command preseed/early_command
diff -ur old/DEBIAN/templates new/DEBIAN/templates
--- old/DEBIAN/templates 2014-09-24 06:16:33.000000000 +0100
+++ new/DEBIAN/templates 2015-06-15 01:24:27.396000000 +0100
@@ -1048,3 +1048,13 @@
 Default: d-i/jessie/./preseed.cfg
 Description: for internal use; can be preseeded
  Path added to local server to give the preseed root
+
+Template: preseed/accept_preseed_from_DHCP
+Type: boolean
+Default: false
+_Description: Accept a preseed URL from the DHCP server?
+ The DHCP server has provided extra commands or customisations to
+ debian-installer via a preseed file. It is possible that these
+ commands were set by the network administrator; however, it is
+ impossible to verify this, or to ensure they have not been altered
+ by an attacker who already has access to your local network. For
+ this reason, you should only accept these customisations if you
+ accept the risk they entail.
 Template: debian-installer/network-preseed/title

I've made it slightly more verbose as well. Is this acceptable, or
should I solicit comments on debian-l10n-english@lists.debian.org?

Thanks for your guidance here.

- Aliz Hammond

Quoting Aliz 'Randomdude' (randomdude@gmail.com):

s/has provided/provided

Better English, imho....

s/your local network/the local network


It is always a good idea to ask for a review in
debian-l10n-english..:-)

         :-(



We have allready 'auto-install/enable'  ( 'auto' for short )

See also https://www.debian.org/releases/jessie/mips/apbs02.html.en#preseed-auto



Geert Stappers

Which does not serve the same purpose.

auto-install/enable reorders some questions (including about networking)
so that you can put more information in the preseed URL and less
information in the command line preseed keys which you need to pass
along with auto-install/enable.

This is about enabling preseeding in the first place.

If you're going to use auto-install, you're most likely also going to
provide a preseed URL, so then having an unexpected preseed URL in DHCP
is fishy.

If you *are* going to provide the preseed URL via DHCP, then it's
perfectly possible to preseed the "accept preseed from dhcp" option on
the kernel command line.

However, I would personally feel more comfortable about this if it were
bypassed when the system has booted from PXE. As said before, in that
case you're already implicitly trusting your DHCP server, so it makes no
sense asking for it anymore.