Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: utf-8
Content-Length: 5314
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