On 29/06/2021 16:10, Erin Shepherd wrote:
Jon Maloy <[email protected]> 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
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
