Bug#396958: /usr/bin/X: several off-by-one errors in debian/local/xserver-wrapper.c
Package: x11-common
Version: 1:7.1.0-5
Severity: normal
File: /usr/bin/X
Hello,
recently I discovered the following bits of code in the source file
debian/local/xserver-wrapper.c (function 'main', starting at line
172):
int
main(int argc, char **argv)
{
...
char line[1024];
char var[64];
char value[256];
...
val = fgets(line, 1024, cf);
while (val != NULL) {
var[0] = '\0';
value[0] = '\0';
if (sscanf(line, " %64[A-Za-z0-9_] = %256[A-Za-z0-9_ -] ",
var, value) > 0) {
This use of 'sscanf' is unsafe and leads to a buffer overflow if
either the key is >=64 characters long or the value is >=256
characters long (the trailing '\0' spills over). From the GNU libc
manual:
* Provide a buffer to store it in. This is the default. You should
provide an argument of type `char *' or `wchar_t *' (the latter of
the `l' modifier is present).
*Warning:* To make a robust program, you must make sure that the
input (plus its terminating null) cannot possibly exceed the size
of the buffer you provide. In general, the only way to do this is
to specify a maximum field width one less than the buffer size. ...
Thus the offending line should read
if (sscanf(line, " %63[A-Za-z0-9_] = %255[A-Za-z0-9_ -] ",
var, value) > 0) {
instead.
Some lines later the following bit of code can be found:
char xserver[1024];
...
i = readlink(X_SERVER_SYMLINK, xserver, 1024);
...
xserver[i] = '\0'; /* readlink() does not null-terminate the string */
Again this is an off-by-one error. 'readlink' will happily return
1024 for long link targets (assuming that the file system allows
this), and the assignment to 'xserver[i]' will overflow the buffer
'xserver' then.
Neither of these issues looks especially exploitable to me but it
might be good to fix them anyway. (Note that this code is part of an
suid root binary.)
I hope this helps,
Jochen
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.1
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Versions of packages x11-common depends on:
ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy
ii debianutils 2.17.3 Miscellaneous utilities specific t
ii lsb-base 3.1-18 Linux Standard Base 3.1 init scrip
x11-common recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
Hello Thomas, On Tue, Mar 08, 2005 at 11:06:03AM -0500, Thomas Dickey wrote: > On Tue, Mar 08, 2005 at 03:46:56PM +0000, Jochen Voss wrote: > > Hello Thomas, > > > > On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote: > > > thanks. Actually I had forgotten the TCSETA detail, but noticed the > > > hardware platform which seems to be relevant as well. > > Is the TCSETA ioctl documented in some publicly accessible place? > > For instance Solaris' termio manpage says this: > > TCSETA >The argument is a pointer to a termio structure. >Those terminal parameters that can be stored in a ter- >mio structure are set from the values stored in that >structure. The change is immediate. And do you know what it means to set the CS7 flag in c_cflags? The libc manual just sais "This specifies seven bits per byte", which sounds like it should never be set on todays hardware? Maybe the call is perfectly right to return an error code for this setting? All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
Hello Thomas,
On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote:
> thanks. Actually I had forgotten the TCSETA detail, but noticed the
> hardware platform which seems to be relevant as well.
Is the TCSETA ioctl documented in some publicly accessible place?
Just for reference: In the failure case (eigthBitInput: false) the ioctl
argument is as follows.
(gdb) p tio
$1 = {c_iflag = 768, c_oflag = 3, c_cflag = 2575, c_lflag = 1487,
c_line = 0 '\0',
c_cc =
"\003\034\177\025\004\001\000\000\000\000\027\022\032\021\023\026\017", '\0'
, c_ispeed = 0, c_ospeed = 0}
The call returns -1 in this case and HsSysError is called.
If I set "eigthBitInput: true", then the argument to ioctl is
(gdb) p tio
$1 = {c_iflag = 768, c_oflag = 3, c_cflag = 2831, c_lflag = 1487,
c_line = 0 '\0',
c_cc =
"\003\034\177\025\004\001\000\000\000\000\027\022\032\021\023\026\017", '\0'
, c_ispeed = 0, c_ospeed = 0}
(only difference: the c_cflag member has bit 9 set, which looks like
the switch from CS7 to CS8). This time the call succeeds.
Maybe its a kernel or libc bug after all?
All the best,
Jochen
PS.: I was unsure which bug report entry I should forward this
information to. I choose "my" copy of the bug report. Hope that this
is ok.
--
http://seehuhn.de/
signature.asc
Description: Digital signature
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
Package: xterm Version: 4.3.0.dfsg.1-12 Severity: normal Hello, on my shiny new Apple Powerbook G4 I encounter the problem described in (closed) bug #105874. The problem is the following: When I try to start xterm with eightBitInput set to false, I opens a window for a fraction of a second but then dies with the error message xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1 The problem goes away when I set eightBitInput to true. The problem did not occur when a virtually identical configuration was used on an i386 based system. My feeble debugging attempts could narrow down the source of the problem a little bit: the error message is caused by the following lines of code (xterm/main.c, lines 3547-3548): if (ioctl(ttyfd, TCSETA, &tio) == -1) HsSysError(cp_pipe[1], ERROR_TIOCSETP); This is executed in the child process after the fork, and the error condition is reported back to the parent process via a pipe in an a little bit convoluted manner. Some information about my laptop can be found on my home page at http://seehuhn.de/comp/powerbook/ . If you need any further information please ask. I hope this helps, Jochen -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.11 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages xterm depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libexpat11.95.8-1XML parsing C library - runtime li ii libfontconfig1 2.2.3-4 generic font configuration library ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-12 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm6 4.3.0.dfsg.1-12 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-12 X Athena widget set library ii libxext6 4.3.0.dfsg.1-12 X Window System miscellaneous exte ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-12 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-12 X pixmap library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-12 X Toolkit Intrinsics ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii xlibs-data 4.3.0.dfsg.1-12 X Window System client data -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#95951: xlibs: [libICE] message replies do not work properly for subprotocols
Hi Branden, On Tue, Nov 26, 2002 at 07:56:42PM -0500, Branden Robinson wrote: > I've attached an updated version of your patch, which applies to > xf-4_2-branch. Did you? I've not seen the patch, neither in the mail nor in the bug report log. I hope this helps, Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html pgp7mq8lVaGFg.pgp Description: PGP signature
Bug#95951: xlibs: [libICE] message replies do not work properly for subprotocols
Hi Branden, On Tue, Nov 26, 2002 at 07:56:42PM -0500, Branden Robinson wrote: > I've attached an updated version of your patch, which applies to > xf-4_2-branch. Did you? I've not seen the patch, neither in the mail nor in the bug report log. I hope this helps, Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html msg04917/pgp0.pgp Description: PGP signature
Re: testers wanted for xfree86 4.1.0-14pre15v1
Hello, On Fri, Mar 08, 2002 at 05:17:13PM -0500, Branden Robinson wrote: >* debian/xserver-xfree86.config: > [...] > - handle case where mdetect returns no output at all; also, break out of >autodetection loop after one iteration if the autodetection question is >not being aksed ^^ This seems to be a typo. Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html
Re: testers wanted for xfree86 4.1.0-14pre15v1
Hello, On Fri, Mar 08, 2002 at 05:17:13PM -0500, Branden Robinson wrote: >* debian/xserver-xfree86.config: > [...] > - handle case where mdetect returns no output at all; also, break out of >autodetection loop after one iteration if the autodetection question is >not being aksed ^^ This seems to be a typo. Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
