Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
unikernels crash on receipt of malformed TCP options #56
Unikernels running with the
The unikernel then exits.
I'm looking into the root cause, which I expect is somewhere in
This is a really interesting bug. A quick code review in
We don't respect the length of the MSS field here, and so assume that we can read a length of 2 bytes from the Cstruct. Ordinarily, this should result in a bounds check failure since the Cstruct view has a smaller size. So why didn't we get a bounds check failure in this case?
This is a relatively benign bug (without type safety, it could easily be possible to corrupt memory allocator data structures, but is "just" a denial of service as-is), but it's extremely bad practise to read memory locations that we should not have access to.
Things it would be good to verify and/or fix in the code:
The actual packet used in this report isn't a valid TCP packet, so I'm not too worried about just rejecting it. Ideally without a crash :-)
added a commit
Jul 2, 2014
On 07/02/2014 07:56 AM, Anil Madhavapeddy wrote:
I have a fix for the length checking in Options.ml - in implementing
I'm checking now to see whether this behavior occurs with a 4.00.1 compiler.
@avsm our use of cstruct is encapsulated in try .. with (which then produces a monadic fail -- thus we don't do length checks in code, but we catch the exceptions https://github.com/mirleft/ocaml-tls/blob/master/lib/reader.mli and https://github.com/mirleft/ocaml-tls/blob/master/lib/reader.ml#L21 )
The bug is due to the Cstruct.BE and LE modules not checking that the length of their view has been exceeded. There's a bound check error if the overall buffer is violated. In the case here, we are reading into the rest of the tcp packet