Hi.

It seems that the client requests (and applies) settings, even though they were removed
from /etc/dhcp/dhclient.conf.
e.g. below, I removed domain-search, nevertheless, the value from the dhcp server is written
to resolv.conf.

Given that this affects DNS a rogue DHCP server could easily use this for attacks.

Cheers,
Chris.

I can confirm such behaviour, but I don’t think it’s a bug:
The `request` setting really only specifies what options the client’s request contains. The server then replies with some arbitrary options, which may or may not match the requested. The client applies whatever options that response contains.
I verified using Wireshark that the protocol is being followed and options missing from the config really aren’t requested.

I don’t think „rogue DHCP server“ is part of the threat model at this point: The client just trusts the server and if it’s a rogue one, the network admin is supposed to get rid of it and in the meantime, you’re also in trouble for the options you actually requested.

However, there appears to be no way to just ignore certain options from the request: You can use `supersede`, but it only allows to force a specific value and not to remove the option entirely. See my Unix & Linux Stack Exchange question [1] on that.
I filed a feature request for that with ISC, but unfortunately, they don’t have a public bugtracker.

Regards,
Felix

[1] http://unix.stackexchange.com/q/120009

Hey.

Still cannot believe that this hasn't been dealt with after so many
years... o.O

As explained previously, dhclient doesn't seem to allow to disable
certain security relevant options from being received (and configured)
from the server.

For example, even when setting:
request subnet-mask, broadcast-address, time-offset, routers,
        domain-name-servers,
        dhcp6.name-servers, dhcp6.fqdn,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes;

It would still take ntp servers, domain search path, etc. from the
server if that offers it.

These values however are quite security critical.
A rogue DHCP server may direct any client (e.g. a notebook connected to
any public network) to use a evil NTP server, which could ultimately
lead to a wrong system time being set, which in turn could lead to
expired certificates, software updates, etc. being used.

Similar, playing around with the domain search path could trick a
system into using/trusting/etc. the wrong names.

supersede isn't really of any help here since a) it doesn't seem to
properly work in all places, and b) one cannot use it do just "unset" a
server provided value (i.e. using the empty string or so doesn't work).


I just stumbled over this issue again, when we observed a successful
attack on two of our institutes notebooks.
Turned out in the end that their time/date must have been influenced
maliciously...


Michael, I've seen you've removed important, security and added
unreproducible without any further explanations... o.O

Adding these back, as the above examples clearly show that this can be
exploited,... further removing unreproducible as it was even confirmed
before by Felix and reproduction seems straight-forward.

Cheers,
Chris.

control: tag -1 upstream
control: tag -1 -security
control: forwarded -1 ISC bug #35631
control: retitle -1 dhclient adopts dhcp server's settings despite
them not being "request"ed

The syntax may very well be a bit odd, but a few minutes of
intellectual poking with supersede leads to a simple solution for all
of the problems mentioned so far.  That is left as an exercise for the
astute reader.

Please feel free to add the security tag once your request for a CVE
id goes through.  For now, since there are simple workarounds, and
given that this is an upstream design flaw rather than a
Debian-specific issue, further effort on solving it should go there.
Good luck!

Best wishes,
Mike

control: tag -1 upstream
control: tag -1 -security
control: forwarded -1 ISC bug #35631
control: retitle -1 dhclient adopts dhcp server's settings despite
them not being "request"ed

The syntax may very well be a bit odd, but a few minutes of
intellectual poking with supersede leads to a simple solution for all
of the problems mentioned so far.  That is left as an exercise for the
astute reader.

Please feel free to add the security tag once your request for a CVE
id goes through.  For now, since there are simple workarounds, and
given that this is an upstream design flaw rather than a
Debian-specific issue, further effort on solving it should go there.
Good luck!

Best wishes,
Mike

Working with you is always uhm... like Christmas... o.O
The solution can't be to use supersede, as this requires one to
actually set a secure/usable value.

For many there may not be a value which one desires to set (e.g. dns
search)... for others, e.g. ntp-servers the best one could do is to use
localhost, which is however not working either, as software then
actually tries to query NTP at localhost.
I never said it's a debian specific bug, but since upstream hides
behind not even having a proper bugtracker its probably pointless to
have one further iteration of pressing there.
Effectively only the distros would be powerful enough to build up the
necessary pressure for upstream to do something.

Given that you're from the security team, I guess removing the security
tag means effectively that the security denies any issue that upstream
doesn't want to deal with to be a security issue.
And further, an attack vector that, as shown above with the expiry of
X509 certs, can be clearly any extremely simply be used isn't
considered worth to be fixed by Debian?

Just simulated that before... set up a local forged NTP server, sent it
via dhcp, when a node in the network reboots at least ntpdate takes
this up and sets any arbitrary date... voila... one can use expired
certs again..


Security-ignorance at it's finest o.O

Seriously, just stop.  The never-ending negativity helps no one.

Absolutely not the point.  You apparently couldn't figure out
supersede and yet it is trivially figure outable.  That is all that
particular paragraph stated.

What about an ntp pool that is already somehow marginally trusted,
like the debian ones used by default in the ntp package?

The point was missed yet again.  If an issue affects all of the open
source community need to be defended in front of the entire open
source community.

No, absolutely not, and point yet again completely missed.

If you are in fact capable of defending your claims in front of peers,
then let's absolutely treat this as a security concern.  If not, then
I have no interest in being the lackey dealing with the never-ending
insult and incompetence.

Good work, should be excellent justification for your CVE request
(with real details of course)!

Best wishes,
Mike

Seriously, just stop.  The never-ending negativity helps no one.

Absolutely not the point.  You apparently couldn't figure out
supersede and yet it is trivially figure outable.  That is all that
particular paragraph stated.

What about an ntp pool that is already somehow marginally trusted,
like the debian ones used by default in the ntp package?

The point was missed yet again.  If an issue affects all of the open
source community need to be defended in front of the entire open
source community.

No, absolutely not, and point yet again completely missed.

If you are in fact capable of defending your claims in front of peers,
then let's absolutely treat this as a security concern.  If not, then
I have no interest in being the lackey dealing with the never-ending
insult and incompetence.

Good work, should be excellent justification for your CVE request
(with real details of course)!

Best wishes,
Mike

Uhm... IIRC it was you who publicly denounced me on d-d and some other
places.
When I wrote you a mail later, trying to talk about that behaviour, I
got no replay... so I don't think I'm negative but rather realistic.
I don't understand what you mean by " You apparently couldn't figure
out supersede"

I even wrote about it in message #31... o.O

Left aside, that NTP by itself isn't secured in any way (i.e.
cryptographically)... people could in principle set up a VPN to a NTP
server they know they can trust.

But even if that isn't done, I don't see how using the debian pool
helps.
If the DHCP advertises it's own evil NTP server, than that will be
used. At least ifupdown does so (network manager interestingly seems to
ignore that part of DHCP).
Sure it does affect the whole community. But as I've said, upstream
didn't react back then when I originally reported that bug. I did
report it once again with more clear exploitation examples.. let's see
what comes up, though I have little hope.

The best one could do right now (except waiting for a NTP successor) is
do confine the problems a bit at the DHCP level.
And for attacks based on mangling around with the DNS search list, the
proper solution is at the DHCP client, it simply shouldn't accept it
(same for several other parameters).
And I hope I don't need to explain, that a sane security policy is to
only whitelist those properties one really wants and not to blacklist
those one doesn't want.
Then it makes no sense to have the tag and severity removed.
As my example showed (and that was just one using NTP), most kinds of
crypto/security system that somehow depend on time, may be probably
attacked by injecting bad time servers to the client.

So it definitely has a high impact and it is security related.
Taking the definition from https://www.debian.org/Bugs/Developer#tags

This doesn't mention that it only applies to issues at Debian, or to
issues that can easily be fixed.
It also doesn't state that it would apply to code security issues (i.e.
buffer overruns or so).
And where would I have insulted you? Which is quite some irony given
that you describe me at the same sentence with incompetence...

The only thing negative I can find in my mail is
"Security-ignorance at it's finest o.O"
which simply describes that fact that this issue is apparently ignored
in Debian (based already on the fact that the security-tag is removed).
It doesn't claim anything about you, whether you're smart, supid,
friendly, hostile or anything else.
AFAIU, people couldn't just directly request CVEs, can they?
I though that need to happen via a CNA, which Debian, to my knowledge,
was one.

Anyway. I wasn't aware that only security issues with a CVE may be
recorded and marked as such in the Debian BTS.
And countless other bugs, which are either marked security or upstream
seem to confirm that this is in fact not the case.

Please go write SecureNTP then.

Then you shouldn't use the Debian ntp package or any other Debian
package at all for that matter.

Like I said, the security tag is for now removed because I am not
going to deal with it as a security issue until you defend it to your
peers.  I am not interested in looking at it because I am far beyond
my tolerance threshold with your behavior.

It is up to you to change that.

Clearly prior behavior plays a huge role here.

CNA's only issue ids for non-public issues.  Absolutely anyone can and
should send CVE requests to oss-sec for issues that are already
public.

That is not true.  But like I said, I am not interested in dealing
with your negativity any more, so please make your case to others.

Best wishes,
Mike

Then I guess one can also close this bug as wontfix, suggesting any
people not to use such packages or try to improve the situation within
Debian.
Who are my peers? I described the issue, no one brought up a valid
argument why this cannot be abused... what else do you want? A paper,
peer-reviewed and published in Nature?
"Your tolerance treshold" ... funny... but even if I'd be a jerk, other
users will thank you for hiding the security issue away by removing
tag, just because you don't like me.
As said before, I wrote you a mail when you said some unpleasant things
about me several times, but didn't get any reply...
The ball wouldn't be in my half of the fiel.
Well the only other
matter I can remember where we have had more direct interaction was
about the blob issues in chromium.
Apparently these are there and not just made up in my mind, others have
reported it as well and even when that specific last case where I was
involved was allegedly not possible to abuse, I still don't see a crime
in reporting such cases and having it cleared up.

Some people may not worry about software shipping blobs, or at least
having framworks in place to download such (like Firefox does with
OpenH264),... other however do and their case isn't less valid.

I'm afraid that others took that ticket up and made some big news out
of it even if it didn't turn out to be a big issue,... but that isn't
my fault.


So other than - I don't know the exact words you accused me last time -
"not contributing code" or something like this... I don't see much
wrong behaviour on my side.


Anyway... since apparently this won't get solved, may I suggest that we
close the bug as wontfix?

Cheers,
Chris.

To interpret that correctly, you need the prior context.  I'm wasting
my time explaining this, but here goes.  The point was that if you're
unwilling to trust the debian ntp pool, then you should also mistrust
the debian ntp package which by default chose that "evil" debian ntp
pool, and if you're so inclined to not trust debian packages like ntp,
then you might as well distrust all debian packages, and give up.
It's called reductio ad absurdum.  Please try to keep up.

How can I possibly make it any clearer?  Go to oss-sec.  Those are
your peers.  Why is this so difficult?

I've clearly described how to get your precious merit badge back.  Why
are you unwilling to defend yourself against your peers?

And you got that absolutely wrong too.  The chromium packages were not
built with native client, so the native client blob was totally inert.

No, go to oss-sec and make your case.  You can earn your precious
trivial security tag by doing real quality analysis and defensible
work.

Best wishes,
Mike