[devel] Fw: [sane-devel] saned bug: possible remote DoS (denial of service)

[Sergey Vlasov "Сергей Власов"]

Что будем делать по этому поводу?



Begin forwarded message:

Date: Sun, 9 Feb 2003 17:47:44 +0100
From: Henning Meier-Geinitz <henning на meier-geinitz.de>
To: SANE Mailing List <sane-devel на mostang.com>
Subject: [sane-devel] saned bug: possible remote DoS (denial of service)


Hi everyone,

Summary:
--------

The SANE network scanning dameon (saned) contains a combination of
bugs that allow a remote attacker to cause a segfault and/or consume
arbitrary amounts of memory. The attack is successful, even if the
attacker's computer isn't listed in saned.conf.


Vulnerable:
-----------

sane-backends-1.0.10 and all previous versions

You are only vulnerable if you actually run saned e.g. in xinetd or
inetd. If the entries in xinetd/inetd are commented out or do not
exist, you are safe.

Try "telnet localhost 6566" on the server that may run saned. If you
get "connection refused" saned is not running.


Counter messures:
----------------

If you run saned, apply the attached patch to sane-backends-1.0.10 or
upgrade to sane-backends-1.0.11 as soon as it will be available.

Generally, saned should be secured by using tcpwrappers and/or a
firewall setup. It's not intended to be used over the internet.
Setting limits for memory consumption is also a good idea.


Details:
--------

a) saned checks the identity (IP address) of the remote host only
   after the first communication took place (SANE_NET_INIT). So
   everyone can send that RPC, even if the remote host is not allowed
   to scan (not listed in saned.conf).
   
b) saned lacks error checking nearly everywhere in the code. So
   connection drops are detected very late. If the drop of the
   connection isn't detected, the access to the internal wire buffer
   leaves the limits of the allocated memory. So random memory "after"
   the wire buffer is read which will be followed by a segmentation
   fault.
   
c) If saned expects strings, it mallocs the memory necessary to store
   the complete string after it receives the size of the string. If
   the connection was dropped before transmitting the size, malloc
   will reserve an arbitrary size of memory. Depending on that size
   and the amount of memory available either malloc fails (->saned
   quits nicely) or a huge amount of memory is allocated. Swapping and
   and OOM measures may occur depending on the kernel.

d) saned doesn't check the validity of the RPC numbers it gets before
   getting the parameters.

e) If debug messages are enabled and a connection is dropped,
   non-null-terminated strings may be printed and segamentation faults
   may occur.

f) It's possible to alocate an arbitrary amount of memory on the
   server running saned even if the connection isn't dropped.


a)-e) are fixed by the patch. f) is not fixed because i think there is
no sensible fix IMHO. Better limit the total amount of memory saned
uses (ulimit).

I don't think that it's possible to run arbitrary commands because
there is no overflow of a buffer that's on the stack.

Thanks to Alexander Hvostov, who orignally found the segfault and
reported it to the Debian bugtracking system and to the Debian SANE
maintainers Julien BLACHE and Aurelien Jarno who helped to find out
what's the actual problem in saned.
   
Bye,
  Henning

----------- следующая часть -----------
An embedded and charset-unspecified text was scrubbed...
Name: sane-backends-1.0.10-1.0.11.diff
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20030212/132edbf7/attachment-0001.ksh>