Bug #28038 for dhcp-public: [patch] Bug in timer code using infinite lease time on 64 bit system

 From: Jiri Popelka <jpopelka@redhat.com>

Subject: dhcpd 4.2 DoS via dhcp client in Android HTC phone
Date: 21 February 2012 13:42:11 CE
To: security-officer@isc.org
Cc: security-response-team@redhat.com, levon@movementarian.org

Hi,

John Levon a Fedora user running dhcpd 4.2.3-P2 (see attached dhcpd.conf) had discovered that his dhcpd server exits very soon after one of the clients (Android HTC phone) obtains an address with:

dhcpd: Timeout requested too large reducing to 2^^32-1
dhcpd: Unable to set up timer: out of range

We have a packed dump (see attached dhcp.pcap) but I haven't been able to find anything strange in it.

I set up a server/client to be as much as possible to John's server/client and tried to reproduce the problem here but with no luck.

So I added some debug messages into the affected code (common/dispatch.c:330) and figured out that the when->tv_sec variable was having value 5624983148 (i.e. over 4G).

This value I think is the reason for the exit but I have no idea where it came from (as I don't see anything like that in the packed dump).

The whole debug output from John's machine is attached as debug_output.txt.

I'm attaching a patch that John confirmed as fixing the problem.

This comment from the patch should explain the problem and the fix:

/*
 * We need to reduce (to 2^^32-1) the absolute time from an epoch
 * (i.e. value of when->tv_sec) and not the relative time (value of
 * sec variable).
 * In other words, we have to make sure that once the
 * isc_time_nowplusinterval() adds current time to the given relativ
 * time the result will be less than 2^^32-1.
 */

This part of code was already "fixed" in 4.2.1b1, changelog comment says:
- Limit the timeout period allowed in the dispatch code to 2^^32-1 seconds.
Thanks to a report from Jiri Popelka at Red Hat.
[ISC-Bugs #22033], [Red Hat Bug #628258]

I remember helping you to test *your* fix then, but unfortunately the test values were probably not huge enough.

Once you have a patch (cause there's one "hack" in mine patch) you can send it to me and I'll build a package/binary for John to test it (if you want).

With regards,
Jiri Popelka
Red Hat, inc.

---

On Thu Feb 23 11:51:58 2012, levon@movementarian.org wrote:
> On Thu, Feb 23, 2012 at 12:40:23PM +0100, Jiri Popelka wrote:
>
> > On 02/22/2012 08:32 PM, Shawn Routhier wrote:
> > >Thank you for your report. We've looked it over and there does
> > >seem to be a problem in the timer code. We're trying to figure
> > >out how it got triggered and how serious it is. Currently we think
> > >it is most likely a configuration issue and so wouldn't be a good
> > >DOS vector.
> > >
> > Yes, nor I've thought it's a security problem since I managed to
> > reproduce it.
>
> What kind of configuration issue? Is there something "wrong" in my
> dhcpd.conf?

Our current theory is that using "infinite" as the lease time is causing
problems as the value gets passed around and eventually gets to
the timer code (when compiled and using a 64 bit OS).  Other numbers
of the appropriate size wold also be an issue.

If so then this would mean that an outside attacker
wouldn't be able to damage the server.

>
> > >While we look into this we were hoping you might be able to
> > >do some tests and gather some information as well.
> > >
> > >Do you know if John tried this with other versions of the code?
> > >Specifically any of the 4.1x versions?
> > >
> > I'll ask but I don't think so as we haven't 4.1 in any supported Fedora
> > version and
> > he wrote that ha was using dnsmasq as a workaround.
> > But I tried to reproduce it with dhcp-4.1.1-P1 and it seems OK
> > (well, it should be as the problematic code was added in 4.2.0).
>
> No, the last working version I tried was whatever was in Fedora 15.
>
> > >In the pcap you sent us the client is receiving a lease time value of
> > >80000, but I don't see anything in the configuration file that would
> > >lead to that value. Does that value ring any bells for you or John
> > >(perhaps an older config file? or something leftover from the client?)
> > >
> > Yes, I had noted that too but forgot to ask John. I'll do that.
>
> I'd experimented with other lease times, so at the time I was using:
>
> default-lease-time 80000;
> max-lease-time 80000;
>
> The bug was still present.

That's curious, I wouldn't expect that to trigger a timer with
a value greater than 4G.

>
> > >While I wouldn't expect it to show much it would be interesting to get
> > >a copy of the lease file to see what the server was trying to record at
> > >the time of failure.
> > I'm attaching mine and will ask John for his.
>
> I'll have to get back to you if you still need it.

What would be best, given your information about the 80000
value would be to try and get a complete set of information from
one example - the config file, the lease file and the error messages
we may eventually want to look at a core dump but I don't
currently have a place to read it so getting it isn't a priority.

>
> regards
> john
>

---

On Tue Mar 13 11:26:00 2012, jpopelka@redhat.com wrote:
> Hi,
>
> Red Hat's Security Response Team would like to know
> whether you consider this to be a security related flaw
> or just an ordinal bug so we could possibly close our
> security-related tickets.
>
> Thank you
>
> --
> Jiri
>
I apologize for the delay in responding.  

Currently we do not consider this to be a security related flaw, as
it appears to be mostly a configuration issue.  However the user
seeing this with a value of 80 000 is a concern.  We never
received additional information for that case though.

---