[Openswan Users] Pluto restart caused by incoming packet possible DOS

[Erich Titl]

Paul

Paul Wouters schrieb:
> On Thu, 30 Apr 2009, Erich Titl wrote:
> 
>>>> Apr 30 08:57:27 gatekeeper-internal pluto[1143]: FATAL ERROR: packet
>>>> from 80.238.212.245:47156: unable to malloc 0 bytes for message buffer
>>>> in comm_handle()
>>>
>>> Are you sure your server did not just leak memory and ran out of ram?
>>> That's
>>> what the error implies.
>>
>> The server definitely did not run out of memory, I am running cacti
>> against it and the graph does not show anything alike. Also these
>> servers typically run 7x24 for months and years with many tunnels open
>> and I never saw anything alike.
> 
> Well, check the code...
> 
> void
> comm_handle(const struct iface_port *ifp)
> {
>     static struct msg_digest *md;
> 
>     md = alloc_md();
> 
> Note that nothing of the packet is actually used here, and you crashed.
> You did not crash on a malicious packet, you crashed do to an internal
> problem.

Of course I do not have your deep insight to pluto's operation, but
pluto did not crash, it stopped gracefully on an allocation of 0 bytes.

Looking at the code I _believe_ it must be due to the following, which
is way past alloc_md

    /* Clone actual message contents
     * and set up md->packet_pbs to describe it.
     */
    init_pbs(&md->packet_pbs
#ifdef NAT_TRAVERSAL
        , clone_bytes(_buffer, packet_len, "message buffer in
comm_handle()")
#else
        , clone_bytes(bigbuffer, packet_len, "message buffer in
comm_handle()")
#endif
        , packet_len, "packet");

because the error message is exactly this one. Now packet_len is 0 in
this case, so no copying can be done anyway.

Looking that the packet_len is determined at

    zero(&from.sa);
    packet_len = recvfromto(ifp->fd, bigbuffer
                            , sizeof(bigbuffer), /*flags*/0
                            , &from.sa, &from_len
                            , &to.sa, &to_len);

and is not modified until to some code in the NAT_TRAVERSAL stuff

recvfromto returns either the return from recvmsg or from revcfrom. If I
understand the manual correctly, this should not occur on UDP

       These calls return the number of bytes received, or -1 if an
error  occurred.  The  return
       value will be 0 when the peer has performed an orderly shutdown.

Anyway, the value of 0 appears not to be checked and is passed to
clone_bytes.

> 
> But without a core file or other data, there is not much to post mortem
> on.

I understand and will of course give details should I ever get them.

Thanks

Erich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3396 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.openswan.org/pipermail/users/attachments/20090503/7ed8f587/attachment.bin