Hi Ben,
comments regarding just the security considerations below.
On 11.09.19 02:03, Benjamin Kaduk wrote:
On Thu, Sep 05, 2019 at 10:02:03PM +0000, Kent Watsen wrote:
On Sep 5, 2019, at 2:07 AM, Benjamin Kaduk via Datatracker <[email protected]>
wrote:
[...]
Section 10
We should warn against implementations scanning past the end of a
buffer (containing the entire contents of a file) when checking what's
in the beginning of the next line -- if a file ends with a backslash
and "end of line" but no further content, we could perform an out of
bounds access if the code assumes it is safe to check for the next
line's initial content.
In a way that is like requiring any IS-IS draft to warn not to blindly
trust the received length value.
I do understand your concern. All input needs to be handled safely.
For example, the "heartbleed" vulnerability was caused by blindly
trusting a length value received from the network.
But validating input and checking buffer boundaries are general
programming concepts and I do not think it useful to single out one (or
a few) and treat them specially in one I-D, but not others. This could
create the impression that checking buffer boundaries is important here,
but not in those other places. And mentioning just the buffer
boundaries ignores the short read that is quite likely to occur at end
of file (the garbage left in the buffer after the last byte read must be
ignored as well, or content integrity is violated, which might change
the meaning of the I-D or add a vulnerability to the code inside the
I-D[1]).
Both Sections 7.2.2 and 8.2.2 describe conditions to determine when
unfolding occurs. AFIACT, in both cases, the unfolding algorithm stays
within the bounds of those conditions.
These procedures are fine if you're operating in a context where you
interact with the text corpus via "get next line" operations. But I don't
think we have limited ourselves to such contexts; consider the case where I
(foolishly) write text-processing code in C, and read(2) the text in
question into a memory buffer. I'm on my own for linebreak detection, and
if I start peeking past escape characters, it's not so hard to imagine that
I could fail to check for "end of buffer" and trigger undefined behavior.
This is true whenever something similar to C and read(2) is used to fill
a fixed size buffer with some bytes. This can create many problems,
e.g., splitting UTF-8 characters, or reading less than the buffer size
(short read, not only possible on EOF). All of those need to be handled
correctly. This holds all the time, not just when implementing the
folding algorithms from this I-D.
Reading more than one byte at a time is an optimization only, it is not
needed for correct function.
This optimization is dangerous, because it adds significant complexity.
Despite this it is used all the time without handling all the corner
cases, so again, I do understand your concerns.
For instance, given the input sequence [ '\' '\n' EOF] , the 7.2.2
algorithm would replace it with [ EOF ] and the 8.2.2 algorithm wouldn't
even attempt to unfold it since the condition of the next line containing
a second '\' character isn't met.
Is this Security Consideration needed?
Well, it's a nonblocking comment. So if the above description seems
totally implausible to you, I can accept it not being included in the
document.
As I see it, the gist of your comment is "implementing the algorithm
incorrectly might result in security vulnerabilities, depending on the
implementation details." But is this a helpful security consideration?
I do not think so.
Thanks,
Erik
[1] Knowing the buffer size (e.g., after probing) could enable to create
input data that creates an XML injection which could result in an
attack on some tool to process I-Ds reachable via Internet. This is
kind of a contrived example, but not completely implausible.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
