[devel] Fw: [sane-devel] saned bug: possible remote DoS (denial of service)
Sergey Vlasov "Сергей Власов"
Ср Фев 12 16:25:16 MSK 2003
Что будем делать по этому поводу?
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)
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.
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.
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.
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
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
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
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.
----------- следующая часть -----------
An embedded and charset-unspecified text was scrubbed...
Подробная информация о списке рассылки Devel