saned: CVE-2017-6318: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Debian Bug report logs - #854804
saned: CVE-2017-6318: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Date: Fri, 10 Feb 2017 10:33:26 -0500

Package: sane-utils
Version: 1.0.25-3
Severity: grave
Tags: security upstream
Justification: user security hole

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.

It may be possible to trigger this bug with other packet types, but I
have not verified this.

I have previously filed a bug in the SANE bug tracker on Alioth
(#315576), but I received no response.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sane-utils depends on:
ii  adduser                3.115
ii  debconf [debconf-2.0]  1.5.60
ii  init-system-helpers    1.47
ii  libavahi-client3       0.6.32-2
ii  libavahi-common3       0.6.32-2
ii  libc6                  2.24-9
ii  libieee1284-3          0.2.11-13
ii  libjpeg62-turbo        1:1.5.1-2
ii  libpng16-16            1.6.28-1
ii  libsane                1.0.25-3
ii  libsystemd0            232-6
ii  libusb-1.0-0           2:1.0.21-1
ii  lsb-base               9.20161125
ii  update-inetd           4.44

sane-utils recommends no packages.

Versions of packages sane-utils suggests:
ii  avahi-daemon  0.6.32-2
pn  unpaper       <none>

-- debconf information excluded

Message #10 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Jörg Frings-Fürst <debian@jff-webhosting.net>

To: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

Cc: sane-devel@lists.alioth.debian.org, 854804@bugs.debian.org, control <control@bugs.debian.org>

Subject: Re: Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Date: Sat, 11 Feb 2017 05:54:37 +0100

[Message part 1 (text/plain, inline)]

tags 854804 + moreinfo
thanks

Hello Kritphong,

thank you for spending your time helping to make Debian better with
this bug report.

I have add the sane-devel ML as cc.


Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
Mongkhonvanit:
> Package: sane-utils
> Version: 1.0.25-3
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> 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.

Or is there an other problem?

Please give us more infos and remove the tag moreinfo with your answer.


> It may be possible to trigger this bug with other packet types, but I
> have not verified this.
> 
> I have previously filed a bug in the SANE bug tracker on Alioth
> (#315576), but I received no response.
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages sane-utils depends on:
> ii  adduser                3.115
> ii  debconf [debconf-2.0]  1.5.60
> ii  init-system-helpers    1.47
> ii  libavahi-client3       0.6.32-2
> ii  libavahi-common3       0.6.32-2
> ii  libc6                  2.24-9
> ii  libieee1284-3          0.2.11-13
> ii  libjpeg62-turbo        1:1.5.1-2
> ii  libpng16-16            1.6.28-1
> ii  libsane                1.0.25-3
> ii  libsystemd0            232-6
> ii  libusb-1.0-0           2:1.0.21-1
> ii  lsb-base               9.20161125
> ii  update-inetd           4.44
> 
> sane-utils recommends no packages.
> 
> Versions of packages sane-utils suggests:
> ii  avahi-daemon  0.6.32-2
> pn  unpaper       <none>
> 
> -- debconf information excluded
> 

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key        : 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_f-f@freenode.net
     j_f-f@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.

[signature.asc (application/pgp-signature, inline)]

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #17 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

To: debian@jff-webhosting.net

Cc: sane-devel@lists.alioth.debian.org, 854804@bugs.debian.org, control <control@bugs.debian.org>

Subject: Re: Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Date: Sun, 12 Feb 2017 00:16:04 +0700

[Message part 1 (text/plain, inline)]

tags 854804 - moreinfo
thanks

On Sat, Feb 11, 2017 at 11:54 AM, Jörg Frings-Fürst 
<debian@jff-webhosting.net> wrote:
> tags 854804 + moreinfo
> thanks
> 
> Hello Kritphong,
> 
> thank you for spending your time helping to make Debian better with
> this bug report.
> 
> I have add the sane-devel ML as cc.
> 
> 
> Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
> Mongkhonvanit:
>>  Package: sane-utils
>>  Version: 1.0.25-3
>>  Severity: grave
>>  Tags: security upstream
>>  Justification: user security hole
>> 
>>  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.

I also have a proof-of-concept that demonstrates this if you'd like to 
take a look at it.

> 
> Or is there an other problem?
> 
> Please give us more infos and remove the tag moreinfo with your 
> answer.
> 
> 
>>  It may be possible to trigger this bug with other packet types, but 
>> I
>>  have not verified this.
>> 
>>  I have previously filed a bug in the SANE bug tracker on Alioth
>>  (#315576), but I received no response.
>> 
>> 
>>  -- System Information:
>>  Debian Release: 9.0
>>    APT prefers unstable
>>    APT policy: (500, 'unstable')
>>  Architecture: amd64 (x86_64)
>> 
>>  Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
>>  Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>  Shell: /bin/sh linked to /bin/dash
>>  Init: systemd (via /run/systemd/system)
>> 
>>  Versions of packages sane-utils depends on:
>>  ii  adduser                3.115
>>  ii  debconf [debconf-2.0]  1.5.60
>>  ii  init-system-helpers    1.47
>>  ii  libavahi-client3       0.6.32-2
>>  ii  libavahi-common3       0.6.32-2
>>  ii  libc6                  2.24-9
>>  ii  libieee1284-3          0.2.11-13
>>  ii  libjpeg62-turbo        1:1.5.1-2
>>  ii  libpng16-16            1.6.28-1
>>  ii  libsane                1.0.25-3
>>  ii  libsystemd0            232-6
>>  ii  libusb-1.0-0           2:1.0.21-1
>>  ii  lsb-base               9.20161125
>>  ii  update-inetd           4.44
>> 
>>  sane-utils recommends no packages.
>> 
>>  Versions of packages sane-utils suggests:
>>  ii  avahi-daemon  0.6.32-2
>>  pn  unpaper       <none>
>> 
>>  -- debconf information excluded
>> 
> 
> CU
> Jörg
> 
> --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key        : 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
> 
> Jörg Frings-Fürst
> D-54470 Lieser
> 
> Threema: SYR8SJXB
> 
> IRC: j_f-f@freenode.net
>      j_f-f@oftc.net
> 
> My wish list:
>  - Please send me a picture from the nature at your home.

[Message part 2 (text/html, inline)]

Message #24 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Jörg Frings-Fürst <debian@jff-webhosting.net>

To: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>, 854804@bugs.debian.org

Cc: sane-devel@lists.alioth.debian.org, control <control@bugs.debian.org>

Subject: Re: Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Date: Sun, 12 Feb 2017 08:43:23 +0100

[Message part 1 (text/plain, inline)]

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@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. 



CU 
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key        : 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_f-f@freenode.net
     j_f-f@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

To: debian@jff-webhosting.net, 854804@bugs.debian.org

Cc: sane-devel@lists.alioth.debian.org, control <control@bugs.debian.org>

Subject: Re: Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

Date: Sun, 12 Feb 2017 16:54:51 +0700

[Message part 1 (text/plain, inline)]

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@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.....@...........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.
>
> CU 
> Jörg
>
>

[signature.asc (application/pgp-signature, attachment)]

Message #42 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Olaf Meeuwissen <paddy-hack@member.fsf.org>

To: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

Cc: debian@jff-webhosting.net, 854804@bugs.debian.org, sane-devel@lists.alioth.debian.org

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

Date: Tue, 14 Feb 2017 23:04:00 +0900

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@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

Message #47 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

To: Olaf Meeuwissen <paddy-hack@member.fsf.org>

Cc: debian@jff-webhosting.net, 854804@bugs.debian.org, sane-devel@lists.alioth.debian.org

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

Date: Wed, 15 Feb 2017 01:02:22 +0700

[Message part 1 (text/plain, inline)]

Hello Olaf,


On 02/14/2017 09:04 PM, Olaf Meeuwissen wrote:
> Could you run
>
>   SANE_DEBUG_SANEI_WIRE=128 saned -d128 2> saned.log
>
> reproduce and provide the saned.log (compressed if big)?
The requested log is attached.

[saned.log (text/x-log, attachment)]

Message #52 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Olaf Meeuwissen <paddy-hack@member.fsf.org>

To: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

Cc: debian@jff-webhosting.net, 854804@bugs.debian.org, sane-devel@lists.alioth.debian.org

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

Date: Sun, 19 Feb 2017 16:53:28 +0900

[Message part 1 (text/plain, inline)]

Hi Kritphong,

Kritphong Mongkhonvanit writes:

> On 02/14/2017 09:04 PM, Olaf Meeuwissen wrote:
>> Could you run
>>
>>   SANE_DEBUG_SANEI_WIRE=128 saned -d128 2> saned.log
>>
>> reproduce and provide the saned.log (compressed if big)?
> The requested log is attached.

Thanks!!

I didn't write the code but, if my analysis is correct, it is actually
worse than sending server memory content over the wire.  It looks like
saned is clobbering memory, i.e. it's writing past the end of allocated
memory, as well.

According to your log (at line 4007), the saned process gets its first
SANE_NET_CONTROL_OPTION request.  That request tries to fetch the value
of the 8th option (compression) which is a string value that can be up
to 1024 (0x400) bytes long.  The request also sends a value with this
request, a NUL-terminated 1-byte long empty string.

# Code line references against f450049b.

At this point we are around line 4045 of the log.  Now let's switch to
the code.  The incoming request is handled in the case statement on line
1979 of frontend/saned.c.  The sanei_w_control_option_req() call has
taken care of the incoming request and the req structure now contains

  req.handle = 0;
  req.option = 8;      // 'compression'
  req.action = 0;      // SANE_ACTION_GET_VALUE
  req.value_type = 3;  // SANE_TYPE_STRING
  req.value_size = 1024;
  req.value      = "\0";

Most importantly, req.value was allocated as a *1*-byte buffer.  This
happens in the if-block starting at line 204 in sanei/sanei_wire.c.
Note that the `len` is passed back up via `len_ptr` but that that value
does *not* make it back to req.value_size because the w_option_value()
call in sanei_w_control_option_req() passes by value, not by reference.

This means that sane_control_option() on line 1999 in frontend/saned.c
happily passes a 1-byte buffer to the backend.  The backend assumes that
it can store up to 1024 bytes in that buffer and writes a NUL-terminated
five byte "JPEG" string into the 1-byte buffer.  Oops!

On line 2003 of frontend/saned.c the reply.value_size is set to the
value fo req.value_size (still 1024) and sanei_w_reply gets a reply
struct that:

 - has a pointer to a 1-byte block of memory
 - which holds a five byte string value
 - that is sent back as a 1024 buffer

Ouch!

This code has been around since the summer of 1999.  Seeing that we have
not had anyone complain about this before, please check my analysis with
care.  I have only "eyeballed" the code.  I have not tried to reproduce
or run things in a debugger or anything.

Attached is a minimal hack/patch that *tries* to fix it.  I have only
checked that it compiles.  Could you take a look at whether it fixes
the issue and does not break saned?

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

[0001-Address-memory-corruption-and-information-leakage.patch (text/x-diff, attachment)]

Message #59 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

To: Olaf Meeuwissen <paddy-hack@member.fsf.org>

Cc: debian@jff-webhosting.net, 854804@bugs.debian.org, sane-devel@lists.alioth.debian.org

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

Date: Mon, 20 Feb 2017 12:00:13 +0700

Hi Olaf,


On 02/19/2017 02:53 PM, Olaf Meeuwissen wrote:
> Attached is a minimal hack/patch that *tries* to fix it.  I have only
> checked that it compiles.  Could you take a look at whether it fixes
> the issue and does not break saned?
Thank you for your patch. I performed some basic tests and it seems to
fix the issue for me. It doesn't break saned as far as I can tell.

Message #64 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Olaf Meeuwissen <paddy-hack@member.fsf.org>

To: Kritphong Mongkhonvanit <kritphong@mongkhonvanit.tk>

Cc: debian@jff-webhosting.net, 854804@bugs.debian.org, sane-devel@lists.alioth.debian.org

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

Date: Mon, 20 Feb 2017 21:13:12 +0900

Hi Kritphong,

Kritphong Mongkhonvanit writes:

> Hi Olaf,
>
>
> On 02/19/2017 02:53 PM, Olaf Meeuwissen wrote:
>> Attached is a minimal hack/patch that *tries* to fix it.  I have only
>> checked that it compiles.  Could you take a look at whether it fixes
>> the issue and does not break saned?
> Thank you for your patch. I performed some basic tests and it seems to
> fix the issue for me. It doesn't break saned as far as I can tell.

That's good news.

@sane-devel> If some of you could review the patch[0] and do some
             testing that would be appreciated.

 [0] http://lists.alioth.debian.org/pipermail/sane-devel/2017-February/035054.html

If someone is willing to pull saned through valgrind and post the
results to the mailing list (don't spam the Debian BTS with this,
please), that'd be appreciated as well.
# I'm a just a wee bit worried there is more amiss with saned.

Alternatively, open a tracker issue[1] and assign it to me.

 [1] https://alioth.debian.org/tracker/?func=add&group_id=30186&atid=410366

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

Message #69 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: 854804@bugs.debian.org

Subject: Looks both RC and present in oldstable+stable

Date: Thu, 23 Feb 2017 20:45:07 +0200

Control: severity -1 grave
Control: found -1 1.0.22-7.4

Based on comment #52 I am setting the severity back to grave,
and mark the versions in oldstable and stable as affected.

I have not personally double-checked either of these, but now the
state of the bug will reflect the current result of the discusion.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #80 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Zdenek Dohnal <zdohnal@redhat.com>

To: 854804@bugs.debian.org

Cc: debian@jff-webhosting.net, sane-devel@lists.alioth.debian.org, kritphong@mongkhonvanit.tk, paddy-hack@member.fsf.org

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

Date: Fri, 3 Mar 2017 20:46:54 +0100

[Message part 1 (text/plain, inline)]

Hi,

I tried to enhanced Olaf's patch and I posted it here:

https://paste.fedoraproject.org/paste/qssgq4s0Vtqw6R5wkDWoEV5M1UNdIGYhyRLivL9gydE=

Were my thoughts right and will it solve this issue?

Thank you in advance.

-- 
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.

Every telecommunications Company in the Fortune Global 500 relies on Red Hat.

Find out why at Trusted | Red Hat

[signature.asc (application/pgp-signature, attachment)]

Message #85 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Olaf Meeuwissen <paddy-hack@member.fsf.org>

To: Zdenek Dohnal <zdohnal@redhat.com>

Cc: 854804@bugs.debian.org, debian@jff-webhosting.net, sane-devel@lists.alioth.debian.org, kritphong@mongkhonvanit.tk

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

Date: Sun, 05 Mar 2017 18:40:16 +0900

Hi Zdenek,

Zdenek Dohnal writes:

> I tried to enhanced Olaf's patch and I posted it here:
>
> https://paste.fedoraproject.org/paste/qssgq4s0Vtqw6R5wkDWoEV5M1UNdIGYhyRLivL9gydE=
>
> Were my thoughts right and will it solve this issue?

Thinking you just "backported" the patch (it applies with a fuzz but
otherwise cleanly against 1.0.25) and removed the comments, I almost
overlook your code change!

I think it's my FIXME that misled you but you should *not* substract
req.value_size.  Doing so is worse than what my code does because your
code would substract too much, quite possibly making w->allocated_memory
negative.  My code runs the risk of not substracting enough.

In sanei/sanei_wire.c bytes are allocated to hold req.value based on a
number provided by the network protocol.  This number is large enough to
hold req.value plus terminating NUL and not larger than req.value_size.

# In the original issue, req.value_size is 1024 and req.value = '\0'.
# The code in sanei/sanei_wire.c allocates *1* byte.

What the code in sanei/sanei_wire.c should do is allocate space for
req.value_size bytes (it can't because where the allocation happens this
information is not available).  My patch frees the incorrectly allocate
memory and allocates a chunk that big enough.  It does that in saned.c
to minimize its impact.

# The sanei/sanei_wire.c code is used by saned *and* the net backend for
# I/O in both directions.  To complicate matters, the code is meant to
# transfer arrays and "abused" to transfer strings as if they are arrays
# of characters.  My patch only affects saned's read logic.
# A better patch would actually fix the issue(s) in sanei/sanei_wire.c.

Doing this in saned.c though means that I no longer have access to the
number provided by the network protocol.  I have to rely on the string
length which may be less.  Hence my FIXME comment.

# I was thinking about scenarios where backends might stuff a string in
# a slightly larger buffer than strictly necessary and send the whole
# buffer.

Hope this clarifies a bit,
--
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

Message #90 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Zdenek Dohnal <zdohnal@redhat.com>

To: Olaf Meeuwissen <paddy-hack@member.fsf.org>

Cc: 854804@bugs.debian.org, debian@jff-webhosting.net, sane-devel@lists.alioth.debian.org, kritphong@mongkhonvanit.tk

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

Date: Tue, 7 Mar 2017 16:26:38 +0100

[Message part 1 (text/plain, inline)]

On 03/05/2017 10:40 AM, Olaf Meeuwissen wrote:
> Hi Zdenek,
>
> Zdenek Dohnal writes:
>
>> I tried to enhanced Olaf's patch and I posted it here:
>>
>> https://paste.fedoraproject.org/paste/qssgq4s0Vtqw6R5wkDWoEV5M1UNdIGYhyRLivL9gydE=
>>
>> Were my thoughts right and will it solve this issue?
> Thinking you just "backported" the patch (it applies with a fuzz but
> otherwise cleanly against 1.0.25) and removed the comments, I almost
> overlook your code change!
>
> I think it's my FIXME that misled you but you should *not* substract
> req.value_size.  Doing so is worse than what my code does because your
> code would substract too much, quite possibly making w->allocated_memory
> negative.  My code runs the risk of not substracting enough.
>
> In sanei/sanei_wire.c bytes are allocated to hold req.value based on a
> number provided by the network protocol.  This number is large enough to
> hold req.value plus terminating NUL and not larger than req.value_size.
>
> # In the original issue, req.value_size is 1024 and req.value = '\0'.
> # The code in sanei/sanei_wire.c allocates *1* byte.
>
> What the code in sanei/sanei_wire.c should do is allocate space for
> req.value_size bytes (it can't because where the allocation happens this
> information is not available).  My patch frees the incorrectly allocate
> memory and allocates a chunk that big enough.  It does that in saned.c
> to minimize its impact.
>
> # The sanei/sanei_wire.c code is used by saned *and* the net backend for
> # I/O in both directions.  To complicate matters, the code is meant to
> # transfer arrays and "abused" to transfer strings as if they are arrays
> # of characters.  My patch only affects saned's read logic.
> # A better patch would actually fix the issue(s) in sanei/sanei_wire.c.
>
> Doing this in saned.c though means that I no longer have access to the
> number provided by the network protocol.  I have to rely on the string
> length which may be less.  Hence my FIXME comment.
>
> # I was thinking about scenarios where backends might stuff a string in
> # a slightly larger buffer than strictly necessary and send the whole
> # buffer.
>
> Hope this clarifies a bit,
> --
> 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
Thank you so much for explanation, Olaf. I did not notice that fact
about req.value_size. So what about fetching string length from
sanei_w_array function by parameters sent by reference? Is it acceptable
to change number and type of parameters of functions? I created patch
proposal:

https://paste.fedoraproject.org/paste/KVJpdlIAMcxiovnYF4dhbV5M1UNdIGYhyRLivL9gydE=

It is probably not final version, but I hope I demonstrated my idea. It
was compiled without error.

-- 
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.

Every telecommunications Company in the Fortune Global 500 relies on Red Hat.

Find out why at Trusted | Red Hat

[signature.asc (application/pgp-signature, attachment)]

Message #95 received at 854804@bugs.debian.org (full text, mbox, reply):

From: Olaf Meeuwissen <paddy-hack@member.fsf.org>

To: Zdenek Dohnal <zdohnal@redhat.com>

Cc: 854804@bugs.debian.org, debian@jff-webhosting.net, sane-devel@lists.alioth.debian.org, kritphong@mongkhonvanit.tk

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

Date: Thu, 09 Mar 2017 21:42:48 +0900

Hi Zdenek,

I really appreciate your efforts to come up with a better patch that
what I have posted to the list. To be honest, I don't really like my
patch but it's the best I could come up with without a testsuite (or
setting up a test environment myself for which I don't have time now
anyway).

Read on, there's more at the bottom :-)

Zdenek Dohnal writes:

> On 03/05/2017 10:40 AM, Olaf Meeuwissen wrote:
>> Hi Zdenek,
>>
>> Zdenek Dohnal writes:
>>
>>> I tried to enhanced Olaf's patch and I posted it here:
>>>
>>> https://paste.fedoraproject.org/paste/qssgq4s0Vtqw6R5wkDWoEV5M1UNdIGYhyRLivL9gydE=
>>>
>>> Were my thoughts right and will it solve this issue?
>> Thinking you just "backported" the patch (it applies with a fuzz but
>> otherwise cleanly against 1.0.25) and removed the comments, I almost
>> overlook your code change!
>>
>> I think it's my FIXME that misled you but you should *not* substract
>> req.value_size.  [...]
>>
>> Hope this clarifies a bit,
>
> Thank you so much for explanation, Olaf. I did not notice that fact
> about req.value_size. So what about fetching string length from
> sanei_w_array function by parameters sent by reference? Is it acceptable
> to change number and type of parameters of functions? I created patch
> proposal:
>
> https://paste.fedoraproject.org/paste/KVJpdlIAMcxiovnYF4dhbV5M1UNdIGYhyRLivL9gydE=
>
> It is probably not final version, but I hope I demonstrated my idea. It
> was compiled without error.

Whether it compiles or not is not the important part ;-)
It's gotta work!  Are you able to test?  If not, can you find someone
who can?  Maybe Kritphong?  If not, the whole thing becomes a rather
pointless endeavour.

Having poured over the code for the better part of a weekend, I'd say
the transmission of strings should not be treated as the transmission
of an array (of characters).  It looks to me like the sanei_w_array()
code can be used fine when transferring the constraint member of a
SANE_Option_Descriptor but I am not convinced it is the right thing
to use when *getting* an option's SANE_String value.  When getting an
option's SANE_String value, the code *should* allocate a buffer big
enough to hold the *largest* possible string even if the net backend is
sending a (much) smaller string.  The size of the largest possible
string is given by the SANE_Option_Descriptor's size member for options
that have an option value type of SANE_TYPE_STRING.

# Please refer to the API spec for the details.

Based on a quick look at your patch, you may be heading in the right
direction but I'd really like to see this confirmed by:

 - tests indicating that saned works (as in you can get/set options
   with string values and scan without trouble)
 - packet captures that show no uninitialized bits of memory go fly
   over the wire (we know that the third party hpaio backend will
   trigger these from Kritphong's bug report so that would be a good
   backend to test with).
 - (optionally but very much recommended) an indication that there
   are no memory issues in saned (think valgrind logs)

That's quite a bit of work and testing for which I unfortunately do not
have the time right now.  If you do, then, by all means, go ahead and
whip up a real fix to replace my somewhat iffy patch.

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

Message #102 received at 854804-close@bugs.debian.org (full text, mbox, reply):

From: Jörg Frings-Fürst <debian@jff-webhosting.net>

To: 854804-close@bugs.debian.org

Subject: Bug#854804: fixed in sane-backends 1.0.25-4

Date: Fri, 21 Apr 2017 17:04:12 +0000

Source: sane-backends
Source-Version: 1.0.25-4

We believe that the bug you reported is fixed in the latest version of
sane-backends, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 854804@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jörg Frings-Fürst <debian@jff-webhosting.net> (supplier of updated sane-backends package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 19 Apr 2017 12:07:38 +0200
Source: sane-backends
Binary: sane-utils libsane-common libsane libsane-dev libsane-dbg
Architecture: source all amd64
Version: 1.0.25-4
Distribution: sid
Urgency: medium
Maintainer: Jörg Frings-Fürst <debian@jff-webhosting.net>
Changed-By: Jörg Frings-Fürst <debian@jff-webhosting.net>
Description:
 libsane    - API library for scanners
 libsane-common - API library for scanners -- documentation and support files
 libsane-dbg - API development library for scanners [debug symbols]
 libsane-dev - API development library for scanners [development files]
 sane-utils - API library for scanners -- utilities
Closes: 854804
Changes:
 sane-backends (1.0.25-4) unstable; urgency=medium
 .
   * CVE-2017-6318:
     - New debian/patches/0500-CVE-2017-6318.patch
       + cherry-picked from upstream to fix memory corruption and
         information leakage (Closes: #854804).
Checksums-Sha1:
 87ec5495e8d612aad027ee494cbc4a0d6da7ced8 2483 sane-backends_1.0.25-4.dsc
 9e539a8d188b423385175fd6902a86acd17486d7 111916 sane-backends_1.0.25-4.debian.tar.xz
 118a68870874230bd79c4744539cd869d50fc582 1012304 libsane-common_1.0.25-4_all.deb
 4000b0ec59ca99b8f633d08f3dbed1b25cefbe1d 7044372 libsane-dbg_1.0.25-4_amd64.deb
 5ae402a98fbcb231234b5452deb8db334afe6c21 2268916 libsane-dev_1.0.25-4_amd64.deb
 d45c864e948133bbe23b09d7608e875404bdeda6 2112160 libsane_1.0.25-4_amd64.deb
 f82e31b8c287d24332f8effd022de07617ca8bc9 10456 sane-backends_1.0.25-4_amd64.buildinfo
 196b1a9d4f662bee0da0c904b1a1d5503a3aed6f 224860 sane-utils_1.0.25-4_amd64.deb
Checksums-Sha256:
 4e1b29bd7ee3a53927b12d977636925fd3b5cc9aaf84b226a12abc403abdb3da 2483 sane-backends_1.0.25-4.dsc
 a8dc4d6c377e31b5317fd2f5a28c321c6f212bfe3e8e3957ab1e26a5df9be6ac 111916 sane-backends_1.0.25-4.debian.tar.xz
 a3e74838f9f5090bba717e7fbf3085d7c492104ca3a73a00c6cf4a1ee31bef3b 1012304 libsane-common_1.0.25-4_all.deb
 587fb44ee003a1260f55bff589bc27cf0ac2fee8c3b28f37391ee6888d0c3f76 7044372 libsane-dbg_1.0.25-4_amd64.deb
 c3bde207d8227c8a696d2557d3e11e2d4ef37e96f87f9b0fe4b5df270db4a160 2268916 libsane-dev_1.0.25-4_amd64.deb
 6374ae8b147b02088a0316e742b05530861f3a02a5f5018df551556c4ee89221 2112160 libsane_1.0.25-4_amd64.deb
 67b34404589a78ff147a0ea6db2a2f266643d8d0bb75af06b1fe1b46b9c90a9a 10456 sane-backends_1.0.25-4_amd64.buildinfo
 33e46c78d9f905f7aec9875936e6e8d34c9ff2a5e919ae5fb0685fc2c28a206b 224860 sane-utils_1.0.25-4_amd64.deb
Files:
 acf2151d38381b820a0ac2010d8e0a66 2483 graphics optional sane-backends_1.0.25-4.dsc
 c1c5f8dc218505210dac623a4ce1926d 111916 graphics optional sane-backends_1.0.25-4.debian.tar.xz
 ce2a85f5502279d3d97d41e347258696 1012304 libs optional libsane-common_1.0.25-4_all.deb
 df5e47046e0e7f704118ffd9c3bce874 7044372 debug extra libsane-dbg_1.0.25-4_amd64.deb
 43403de32daa7558ec850addc6f853d4 2268916 libdevel optional libsane-dev_1.0.25-4_amd64.deb
 9a1ebedc9365b89ca5de54667a0d6b9a 2112160 libs optional libsane_1.0.25-4_amd64.deb
 b486f4598d98e2269976d374ba9ac38b 10456 graphics optional sane-backends_1.0.25-4_amd64.buildinfo
 f31f68c60fe3f6d92f330fc397bffb93 224860 graphics optional sane-utils_1.0.25-4_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlj6NxEACgkQdCY7N/W1
+RNhyQ//eehvbqJRmeJ+SF1zpn75xP8wJ9WnvQwYj7hd84itQ1z3exJldOTGxh/W
5h4t5eKPzUM9hP6AZz3ydCxpvTI/XqKb8VM2xOetlP2wJ6GLMgigx0RgIoJz2As0
T2Ni+wocQo+I52qfbKVMOTcYc0cJ7bv286J4OLJP5zFgHv2SNthR/ZWFVbr64fEx
yH0VVl8koX/BSywQ6f7ZHDdNhE2yKVZS3xVgN+qtRh+Vl80esx1/I108j44hfMbx
IE+pCDwwZw8SGT5AkRiQclkg+AOnDIBsWoD8Wfvvst4dpqwpsXbKhBWKCjYYpGm1
SG25Yhdt1vZrxtviOFc8JTMZVGLxFZN51PsskdvSG3ZMlJrF4XpsXxq/WWWcG1O8
5DmI3Ujuh8jCpmhSAHKdFgpUcLZIoAD9RxSpTEEqdPDwlIyrdQoFIV49RgRVIuFi
Z3p8XaBSvrodn9HGDZhju/fSq2ELUsXwcyXbU1xkiNeLpzIUezD7q6iYadVsSrRP
O9XjPgeOTkl3hrRJAPRq7cvX72oLDO7QrG7VbVZ5YxluFES9e7o1s7e94HNlm0Qm
gvOQrhDZhHSTIp8CtZOlXDSF0N/bTFCcTAgd5yzzLqPNWpB5aQMAaSbzMLzJZEZv
bZtrZM6j154+Uy11nZdDT5dsprh+EOBjP615zNF5Cj2qrKtCqMA=
=b5us
-----END PGP SIGNATURE-----

Message #107 received at 854804-close@bugs.debian.org (full text, mbox, reply):

From: Jörg Frings-Fürst <debian@jff-webhosting.net>

To: 854804-close@bugs.debian.org

Subject: Bug#854804: fixed in sane-backends 1.0.24-8+deb8u2

Date: Sat, 22 Apr 2017 13:02:08 +0000

Source: sane-backends
Source-Version: 1.0.24-8+deb8u2

We believe that the bug you reported is fixed in the latest version of
sane-backends, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 854804@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jörg Frings-Fürst <debian@jff-webhosting.net> (supplier of updated sane-backends package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 19 Apr 2017 11:51:22 +0200
Source: sane-backends
Binary: sane-utils libsane-common libsane libsane-dev libsane-dbg
Architecture: source amd64 all
Version: 1.0.24-8+deb8u2
Distribution: jessie
Urgency: medium
Maintainer: Jörg Frings-Fürst <debian@jff-webhosting.net>
Changed-By: Jörg Frings-Fürst <debian@jff-webhosting.net>
Description:
 libsane    - API library for scanners
 libsane-common - API library for scanners -- documentation and support files
 libsane-dbg - API development library for scanners [debug symbols]
 libsane-dev - API development library for scanners [development files]
 sane-utils - API library for scanners -- utilities
Closes: 854804
Changes:
 sane-backends (1.0.24-8+deb8u2) stable; urgency=medium
 .
   * CVE-2017-6318:
     - New debian/patches/0500-CVE-2017-6318.patch
       + cherry-picked from upstream to fix memory corruption and
         information leakage (Closes: #854804).
Checksums-Sha1:
 33053e795f952686e5028297281aa36b915ed6e7 2493 sane-backends_1.0.24-8+deb8u2.dsc
 1a5d4a2967c304baadae0888bc80f2f904a162dc 98460 sane-backends_1.0.24-8+deb8u2.debian.tar.xz
 f1a2cf35413f08e0e0687604a5c8a16d24b4ddb7 223022 sane-utils_1.0.24-8+deb8u2_amd64.deb
 7c915d97f2dda98fd70713096908a066321f3476 1000266 libsane-common_1.0.24-8+deb8u2_all.deb
 ee6dddce67f1cae4167460de8f65479aa74cac18 2038932 libsane_1.0.24-8+deb8u2_amd64.deb
 ea73697040b7a87b991f8218fc8c2bc31043ce73 2208572 libsane-dev_1.0.24-8+deb8u2_amd64.deb
 a4d24bbf50daf3569b25a2b1131f507167de167b 6097174 libsane-dbg_1.0.24-8+deb8u2_amd64.deb
Checksums-Sha256:
 7d29e428eb73cd5de75277099b1d859d9f4fb385694f6d3725cceef7cf92bf55 2493 sane-backends_1.0.24-8+deb8u2.dsc
 3b9fec44fc22c98d270351fe864db96f7a57609d83d93d814f1202dfc230c863 98460 sane-backends_1.0.24-8+deb8u2.debian.tar.xz
 1b6ee13341b376df9edc28f698b8cde7e6269b2848dc28d4bed71873edf587b1 223022 sane-utils_1.0.24-8+deb8u2_amd64.deb
 21930e99a0545c2bc4503ee98e3ba568b1ec954db93919eb4705379d1120d8da 1000266 libsane-common_1.0.24-8+deb8u2_all.deb
 175600336c37db4030f2e61f0743fc1f9ae542cfc883700fada210a9b18ffc92 2038932 libsane_1.0.24-8+deb8u2_amd64.deb
 484bacf3bb28845fc58aed5a53114af44b0e99cf2e5fcddac0d3a03ed179a513 2208572 libsane-dev_1.0.24-8+deb8u2_amd64.deb
 cace5d841a2bbd2f893daae5f5915c0410539357fb67b7b57febb1ba07026895 6097174 libsane-dbg_1.0.24-8+deb8u2_amd64.deb
Files:
 973e15cd6dbf31df84b43c5b2b4f671f 2493 graphics optional sane-backends_1.0.24-8+deb8u2.dsc
 c864348e6538443ecac3a7fc86e56f13 98460 graphics optional sane-backends_1.0.24-8+deb8u2.debian.tar.xz
 7e26630ab519cde672a48f1e4ff46b14 223022 graphics optional sane-utils_1.0.24-8+deb8u2_amd64.deb
 1852ab5d4d494d8373418ea9f4629ed6 1000266 libs optional libsane-common_1.0.24-8+deb8u2_all.deb
 c5bf45d107fd4a464d5bf0e3614dd17c 2038932 libs optional libsane_1.0.24-8+deb8u2_amd64.deb
 32b0fb91e09636334d09c6279b63c5c9 2208572 libdevel optional libsane-dev_1.0.24-8+deb8u2_amd64.deb
 212eab0c1e9a869cafcd5378c06a8c58 6097174 debug extra libsane-dbg_1.0.24-8+deb8u2_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlj6VIcACgkQdCY7N/W1
+ROnaRAArSyE8Kbc6qTJT7sYC0yHT2/HPNgomSYPBPSChVDLVo6X9x2l9zkEgBq7
k6OSR8cQq3UrA5D0SszRsjf82SLukgEuXAsFAjlZmZl1ncyaWKICBALQeK+mKxfW
dKFgWun8WsFWqy+NHSxz86x8DzsfUhRy22rB8rXRh40y+LRtaeEMaUxGYJgbsjdp
/LS8DaCOb2sKqwyPMfVcfVJzwAsFn0YGqerBTm/inyMzyBRxZZOqyB1lWbGOVpaS
+urw0ztPsuAy2PuYf+DMy+tJS9sZKEC6kPiZO/R26vLMUArt1jPDSNID4VeoquR8
7soeZQk6dN7mIQKRCwD+fGTp3hdAXgjsQHBShC1bjRwWaP+Xq5kfagx+wAQ7ooL8
dfm6IcEfr43x6br2dM02ZZWQE6PlArxrhDwN6lXtU4WEL0VQH9kgRITImzhk70rO
j7JEIvvIJ5+Q1S7y9DoQ1sLkw3L/soJjkC88I6DO2y3bsbnGpU4oWSIHccT1yPCD
NXu3eg+jes3C2yCjMtGZgKTqUA0OYIrtLH2rw2bzXbyJjw8UxcHLa4AwzUdgfEaO
utguEJbUgl5SCnBHTiT7S1P6ZjOq5d4MHZ0aM7NIVITeHkDZY6q1v56/tw+egF85
Tkh42ui6itHStsTJFe2hy+ETAYw18lt17Yxqm1vHYBtgUTKYBoA=
=rpgd
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.