[radvd-devel-l] radvd security issues

[Reuben Hawkins]

On Tue, Oct 4, 2011 at 4:07 AM, Vasiliy Kulikov <segoon at openwall.com> wrote:
> (removed netbsd from cc list)
>
> On Tue, Oct 04, 2011 at 00:56 -0700, Reuben Hawkins wrote:
>> On Fri, Sep 30, 2011 at 11:46 AM, Vasiliy Kulikov <segoon at openwall.com> wrote:
>> > 5) process_rs() shouldn't do mdelay() in the same thread in which it
>> > handles all input.  If ->UnicastOnly is set, one may flood with
>> > ND_ROUTER_SOLICIT, fill input queue of our daemon and cause approx.
>> > MAX_RA_DELAY_TIME / 2 * sizeof_input_queue delay in handling new.
>> > clients.
>>
>>
>> Was there a patch for this too?  It seems your patch leaves this code
>> as is.  The radvd spec calls for a random delay before sending a
>> message.  I don't particularly like it, but it's in the RFC (RFC 2461
>> Section 6.2.6).
>
> I don't known how it should be handled now, but this RFC was written in
> 1998, and probably DoS was not considered as an issue.
>
>
> RFC 2461, 6.2.6 also says (look at ignore the random delay part):
>
> "Upon receipt of a Router Solicitation, compute a random delay
> within the range 0 through MAX_RA_DELAY_TIME.  If the computed
> value corresponds to a time later than the time the next multicast
> Router Advertisement is scheduled to be sent, _ignore the random
> delay_ and send the advertisement at the already-scheduled time."
>
> So, radvd shouldn't queue multiple solicits, but answer to them as if to
> a single RS.
>
> Also it seems to me it delays processing packets on other interfaces
> because of sleeps, no?
>

Yes, it does delay processing packets.  I'm going to drop the mdelay.
I've always wanted to.  We're going to define the random delay to
always be zero (It is technically allowed by the RFC after all). ;)


>>  I do test by flooding radvd with ND_ROUTER_SOLICIT
>> already and everything seems fine (aside from pegging the CPU at
>> 100%).
>
> I was thinking about addition of new clients.  E.g. client A sends
> numerous RS, filling radvd's input queuse, then client B comes, and
> B gets the answer with a big delay as radvd is answering for A's RSs
> with unicast packets.  B's packets also can be lost if radvd's queue is
> full.
>
>> >
>> > 6) signal handlers shouldn't call dlog() as dlog() calls fprintf() and
>> > fprintf() is not reentrant, which might lead to memory corruption
>> > (however, I cannot see how it can be controlled by an attacker).
>>
>>
>> Also, there no fix for this in the patch?
>
> Oops!  I've found these after I've written the report, but forgot to
> update the patch.  Thanks for pointing this out, indeed, no fix for 5,
> 6, and 9.
>

Awesome.  If you look at my radvd git repo on github, I've added your
changes to the "security-patches" branch.  It *may* make it simpler
for you to generate a new patch (or at least make it easier for me to
integrate them).

>
> --
> Vasiliy Kulikov
> http://www.openwall.com - bringing security into open computing environments
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBAgAGBQJOiuj/AAoJEBoUx9gkVaZc2REP+gKZF61OxnrjX+lNzoZ5zxAj
> XbPXrNre7DpNkiw/365Gzpa9Fwu5nmosJrbkVKRj6TjLWOisgE6jNfHigXPJzaYn
> jRQw0kJv0RNoBgWfY3nqh+S1rDW7togNUMe8ZN9atYjGwnZG6Gnlvu5TVYerXwXr
> YGf/kTscFbjJjKe1ZdjNSjDm6fq8pEfledV7d/h81wkMg1koyLzZbpmKZLW/VDmC
> U81zFI7UMX5+Jleu5JTgic7gc85dYGrdjU30rNTcYQEwibFI1H6kdOnIwKIpXWUh
> PxuZ1rEoKw216qna/LRJc+H6MQIRg9f5mbbBKJiKdtRL2qa5NaTGgB1hj9pMzsJv
> UszaMQVqcyhlH/em/V6Xw7HJsay1iqKgObAlT1T0+ehg9XHCo3vzvgkUzfGp/xAA
> LNi6KZ9Mx3Uw+o9dVqrgV9sp8w8i7LHhpBaZDn0qASUQef396t4Ov9sm32igPO7f
> YpC3f9H0+RU7kaZWTbfh5yk00MyzKQ/imuGZ+eCVKP2oWiRR7rKgtA5i4U+Ffq9L
> ZU4MxpeXLEWPYVULz15XipSsbsNhoCkvcZQjOtUVHvuaBD8Mu0gTIKCldnBoghD0
> pvLCZSo9OPXsdZXC8vGNnZUmuIvtZXAP4uFb2hMjIqNb1c1bHbV2dngdfXNLBuKK
> jWCUaH5B/uYHvi/YLPEu
> =lw8q
> -----END PGP SIGNATURE-----
>
>