Re: [tipc-discussion] [PATCH net-next] tipc: keep the skb in rcv queue until the whole data is read

[Jon M. <jm...@re...>]

On 29/06/2021 16:10, Erin Shepherd wrote:
> Jon Maloy <jm...@re...> writes:
>> In the latter case we would be on the 100% safe side, although I have a
>> real hard time to see that this could be a real issue. Why would anybody
>> deliberately design an application for having messages truncated.
> My concern would be more around people using the new behavior on
> unsuspecting programs to do "packet smuggling" attacks
>
> Lets say you have Program A sending messages to Program B which contain
> a header followed by some (variable length) data which can be controlled
> by a third party. Program B reads messages into a 1024B buffer.
>
> If I were a malicious attacker, I might try to craft some data for
> Program B to send which places a packet header just to appear just after
> the new split point. With the new behavior, Program B would think this
> was a header (legitimatedly) crafted by Program A. It is entirely
> plausible that this header contains identity/trust information which
> shouldn't be controllable by external third parties
>
> With the existing behavior, Program B probably discards these overlong
> packets either becasue it sees the truncated flag is set, or because
> they are malfformed. With the new behaviour, the first segment would
> probably still get discarded, but follow up segments might look
> plausible
>
>   - Erin

I think a sufficiently dedicated attacker always can find ways to inject 
packets as when the links are not encrypted. But given Xin's new 
suggestion we should be as safe as we can be regarding this scenario.

///jon

>