[sane-devel] Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

[Olaf Meeuwissen]

Hi Kritphong, Jörg,

Kritphong Mongkhonvanit writes:

> Hello Jörg,
>
> On 02/12/2017 02:43 PM, Jörg Frings-Fürst wrote:
>
>> [snip BTS control commands]
>>
>> Hello Kritphong,
>>
>> Am Sonntag, den 12.02.2017, 00:16 +0700 schrieb Kritphong
>> Mongkhonvanit:
>>> [snip BTS control commands]
>>>
>>> On Sat, Feb 11, 2017 at 11:54 AM, Jörg Frings-Fürst <debian at jff-webhosting.net> wrote:
>> [...]
>>>> Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
>>>> Mongkhonvanit:
>> [...]
>>>>  Dear Maintainer,
>>>>
>>>>  When saned received a SANE_NET_CONTROL_OPTION packet with value_type ==
>>>>  SANE_TYPE_STRING and value_size larger than the actual length of the
>>>>  requested string, the response packet from the server contains a string
>>>>  object as long as value_size in the request. The bytes following the
>>>>  actual string appears to contain memory contents from the server.
>>>>
>>>> Please let me explain:
>>>>
>>>> You have found one or more parts in the code where a string with an
>>>> incorrect value_size is transferred? Then please tell us where.
>>>
>>> I found that the transferred string in the value field of
>>> SANE_NET_CONTROL_OPTION response packet is always the same size as
>>> the one requested, even if the actual string is shorter. I assume
>>> that this is intentional since the string is
>>> NULL-terminated. However, the part beyond the NULL-terminator
>>> appears to be uninitialized memory from the server, which can
>>> potentially contain sensitive information. I have yet to locate
>>> where in SANE's source code this is happening, but I am able to see
>>> the uninitialized memory in Wireshark, which suggests that it
>>> actually comes from the server rather than from my machine.
>>>
>> [...]
>>
>> At a short code search I have found a point of use in net.c.
>>
>> The authors are aware that the strings can be shorter than the
>> transferred size. You have written the appropriate code that ensures
>> that the strings only use the part until the final NULL.

That's the `case SANE_TYPE_STRING` in backend/net.c#1753.

>> Furthermore, before using the structure, it is overwritten with NULL.

That's the `memset` in backend/net.c#1767, right?  Or are you referring
to frontend/saned.c#1997?

>> At this point I don't see any security hole. So I set the severity to
>> important. In the future, I will close the bug, unless you create new
>> threats.
>>
> I do realize that there is a part where the memory was zeroed in net.c.
> However, there must be somewhere else where uninitialized memory was
> copied and sent since the bytes following the string are not exclusively
> zeros.
>
> Please take a look at the decoded SANE_NET_CONTROL_OPTION response

If it's in the *response*, then it comes from frontend/saned.c, not the
backend/net.c code.  I've been chasing the code up and down and am by
now fairly sure it is caused somewhere in the sanei/sanei_wire.c code.
I just don't see where.

Could you run

  SANE_DEBUG_SANEI_WIRE=128 saned -d128 2> saned.log

reproduce and provide the saned.log (compressed if big)?
# Running saned through valgrind may also turn up hints, BTW.

> packet I captured in Wireshark below.
>
> ....................JPEG............SignerIdentifier........digestAlgori
> thm......................................................l.=...@@.......
> ....X...........................................8...........AlgorithmIde
> ntifier.....signedAttrs.................................................
> .............`......................................................x...
> `...........SignedAttributes............................................
> ........................................`...............X...0...........
> ....................................signatureAlgorithm..................
> .................................p..... at ...........8...X................
> ....................g.............AlgorithmIdentifier.....signature.....
> .........................................................;... at ..........
> ..........................................................unsignedAttrs.
> ....................................................../#...`..X.......p.
> ......8...................................h...............SignedAttribut
> es....................................
>
> Here's an excerpt of the corresponding hex stream. I omitted the part
> after the string since it looks like it may contain sensitive
> information.
>
> 00000000 00000000 00000003 00000400 00000400 4a504547 00 (omitted)
>
> As you can see, the string "JPEG" is NULL-terminated at byte 25, and the
> bytes after that are clearly not all zeroes. Both value_size (the 4th
> word) and the length of the string object (the 5th word) are set to
> 0x400, so they must have been sent by saned as a part of the string
> object.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join