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

[Kritphong Mongkhonvanit]

Hello Jörg,

On 02/12/2017 02:43 PM, Jörg Frings-Fürst wrote:

> severity 854804 important
> tags 854804 + moreinfo - security
> thanks
>
>
> Hello Kritphong,
>
>
> Am Sonntag, den 12.02.2017, 00:16 +0700 schrieb Kritphong
> Mongkhonvanit:
>> tags 854804 - moreinfo
>> thanks
>>
>> 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.
>
> Furthermore, before using the structure, it is overwritten with NULL.
>
> 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
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.
>
> CU 
> Jörg
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20170212/3dda6491/attachment.sig>