Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: utf-8
Content-Length: 2389

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.

> 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).

> Can the test be run with at least two more values for the lease times
> instead of "infinite"?  The two sets of values that would be interesting
> to us are a large number but less than 2^^31 - 1 and a number between
> 2^^31 and 2^^32 - 1.
>
I tried it with several values and the result depends on whether
the (number + cur_tv.tv_sec) is less or more than 2^32-1

results when cur_tv.tv_sec = 1329992027
-------------------
2000000000                :  ok
2147483647 (2^31-1) :  ok
2700000000                :  ok (2700000000 + cur_tv.tv_sec = 4029992027 
< 2^32-1)
3000000000                :  not ok (3000000000 + cur_tv.tv_sec = 
4329992027 > 2^32-1)
4294967295 (2^32-1) :  not ok

> 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.

> 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.

>
> As normal the fix looks like a good start, we may need to modify it
> for other compilers (as I recall that's why we included the & DHCP_SEC_MAX
> in the previous patch and after we review it some more.
>
Thanks.

--
Jiri