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 >>> <deb...@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.....@...........8...X................ > ....................g.............AlgorithmIdentifier.....signature..... > .........................................................;...@.......... > ..........................................................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 -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
