| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 14 Apr 2004 00:13:48 +0200
From: Rene Wagner <reenoo@....de>
To: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Cc: LCDproc <lcdproc@...ts.omnipotent.net>
Subject: UPDATE: LCDproc Buffer Overflow and Format String Vulnerabilities
LCDproc Security Advisory 2004-04-13
OVERVIEW
Package Name: LCDproc
Vendor URL: http://lcdproc.org
http://sourceforge.net/projects/lcdproc
Problem category: Buffer overflow and format string
vulnerabilities
Versions affected: 0.4.x up to (and including) 0.4.4
CVS HEAD (0.5) before current
Versions not affected: 0.3.x
Risk: highly dependent on individual setup
(see below)
Actions to be taken: upgrade to latest version 0.4.5
or current HEAD for users of the CVS
development (0.5) branch
SUMMARY AND SOLUTION
Multiple possibly remotely exploitable vulnerabilities were published
on bugtraq without prior notice to the authors of LCDproc.
http://www.securityfocus.com/bid/10085
The information provided is partly incorrect and partly misleading.
The provided patches leave affected systems possibly unprotected.
LCDproc 0.4.5 has been released to fix the issues described and is
available from the project website or from SourceForge.net. It is
recommended that all users upgrade to this version.
Similar patches have been committed to the CVS HEAD branch. It is
recommended that all users of this development version upgrade their
systems after running "cvs update -Pd" in the toplevel directory of the
source tree.
GENERAL DISCUSSION
The problems described in the original posting are valid and have to be
taken seriously.
However, versions prior to 0.4.x are not affected since 0.3.x did not
provide any TCP/IP client/server functionality.
The scope of the vulnerabilities also highly depends on the individual
setup of LCDd.
While older versions (0.4.x; x<3)of LCDd bind to 0.0.0.0 and are thus
accessible from any network interface, current versions (>=0.4.3) bind
to localhost (127.0.0.1) only. Any vulnerabilities can only be exploited
from the local system in that case.
Only, if the user decides to change this setting it can become a remote
vulnerability at all.
Also, LCDd drops its priviledges after starting up if possible. For that
to work it has to be run as "root" and must not be configured to use
parallel port devices which require root access.
By default LCDd (>=0.4.3) changes its uid to "nobody". Access through
any exploit is thereby limited to that particular user.
TECHNICAL DISCUSSION -- PATCHES
- LCDproc version 0.4.4
The patch provided by the original posting fails to fix the issue it
tries to resolve and doesn't address another vulnerability.
With the original patch the counter i of the loop inside
parse_all_client_messages() in server/parse.c reaches MAX_ARGUMENTS
which already leads to an overflow.
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/parse.c,v
retrieving revision 1.10.2.2
diff -u -r1.10.2.2 parse.c
-- server/parse.c 29 Dec 2001 15:28:40 -0000 1.10.2.2
+++ server/parse.c 13 Apr 2004 18:07:22 -0000
@@ -158,7 +158,7 @@
argc++;
- } while (*p);
+ } while (*p && i < MAX_ARGUMENTS - 1);
/*debug(RPT_DEBUG, "exiting string
scan...");*/
The format string vulnerability inside test_func_func() in
server/client_functions.c is not addressed for LCDproc 0.4.4.
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/Attic/client_functions.c,v
retrieving revision 1.19.2.12
diff -u -r1.19.2.12 client_functions.c
-- server/client_functions.c 10 Apr 2002 12:35:54 -0000 1.19.2.12
+++ server/client_functions.c 13 Apr 2004 18:08:59 -0000
@@ -94,7 +94,7 @@
for (i = 0; i < argc; i++) {
snprintf (str, sizeof(str), "test_func_func: %i ->
%s\n", i, argv[i]);
- report (RPT_INFO, str);
+ report (RPT_INFO, "%s", str);
sock_send_string (c->sock, str);
}
return 0;
- LCDproc CVS HEAD branch (also known as 0.5)
The corresponding patches:
Index: server/parse.c
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/parse.c,v
retrieving revision 1.16
diff -u -r1.16 parse.c
-- server/parse.c 17 Jul 2002 22:09:06 -0000 1.16
+++ server/parse.c 13 Apr 2004 18:10:52 -0000
@@ -154,7 +154,7 @@
argc++;
- } while (*p);
+ } while (*p && i < MAX_ARGUMENTS - 1);
/*debug(RPT_DEBUG, "exiting string scan...");*/
Index: server/commands/client_commands.c
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/commands/client_commands.c,v
retrieving revision 1.3
diff -u -r1.3 client_commands.c
-- server/commands/client_commands.c 14 Jul 2002 20:30:35 -0000
1.3
+++ server/commands/client_commands.c 13 Apr 2004 18:10:53 -0000
@@ -45,7 +45,7 @@
for (i = 0; i < argc; i++) {
snprintf (str, sizeof(str), "%s: %i -> %s\n",
__FUNCTION__, i,
argv[i]);
- report (RPT_INFO, str);
+ report (RPT_INFO, "%s", str);
sock_send_string (c->sock, str);
}
return 0;
ADDITIONAL INSTRUCTIONS
Apart from upgrading, users of LCDproc can improve security by acting
according to the following instructions.
It is highly recommended that users leave the default
Bind=127.0.0.1
setting in their LCDd.conf ([server] section) and use third-party tools
like stunnel or ssh to allow secure, encrypted connections to LCDd from
remote systems.
The default
User=nobody
is already reasonably secure, but a few notes are neccessary. To drop
priviledges by changing to the supplied user id, LCDd needs root
priviledges on startup.
For parrallel port devices this is not possible since root priviledges
are neccessary to access the parallel port on most *NIX systems.
It should also be noted that the choice of "nobody" is not optimal.
The "nobody" account can be found in most default *NIX installations
and is typically used by programs that are supposed to have very
limited access to the system. This makes it very likely that other
programs run as "nobody" already, giving LCDd access to their data
(if any) and the possibility to kill those processes etc. if it also
runs as "nobody".
Users should create a new, separate user account solely for LCDd for
maximum security in this respect.
ADDITIONAL CREDITS
Thanks to
- Scott Rowe for pointing to the original bugtraq-posting on the
LCDproc mailing list
- Ingo van Lil for an initial analysis of the problems
Copyright (C) 2004 - Rene Wagner
LCDproc-stable maintainer
http://lcdproc.org
Powered by blists - more mailing lists