Thread by @xnyhps

We had a short look at the buffer overflow found by fuzzing `process_browse_data` to determine its exploitability. Conclusion: this bug alone won't give you RCE, or even an info leak.

https://twitter.com/evilsocket/status/1839394447286751430

It's an out-of-bounds read of 1 byte past the end of a stack buffer. In various places the following condition is used to determine whether to stop processing:

*c != '\"' && c < end

github.com/OpenPrinting/c…

This should be the other way around: currently, once c == end, it will still check if *c == '\"' first, reading 1 byte past the end of the packet buffer.

Can this leak anything important? The function will always bail if it reaches this condition, so at best it will introduce a (tiny) timing difference based on whether the first byte after the packet buffer is 0x22 or not. What is at that location will depend on the compiler.

For the i386, ARM64 and ARMHF Debian packages for cups-browsed, the stack location after it contains the stack canary, which would be very interesting to leak. However, on Linux the stack canary always starts with a NUL byte, so leaking the first byte is not useful.

In the AMD64 package, there's 8 bytes of padding between the end and the stack canary, which could contain uninitialised data, depending on the previous function that occupied this stack area.

This timing difference will be very, very hard to observe remotely (we're talking about skipping ~2 instructions), and it just indicates whether the value is 0x22 or something else. So as an information leak, this is not very useful. RCE with just this read is impossible.

However, it is a vulnerability and should be fixed, and it should be interpreted as a sign that there might be other parsing bugs, so further auditing/fuzzing is a good idea.