Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
On Wed, Apr 12, 2006 at 05:59:45PM +0200, Moritz Muehlenhoff wrote:
> > The Debian security FAQ says that non-free is not supported, and I
> > understand why. But it also says that if it is fixable, an update can be
> > made. There were (a few) non-free security updates in the past.
> >
> > I see that Bruno is alive :) If he reviews my patch for Sarge and if the
> > security buildds have CPU time available, is it possible to release an
> > update? I can write a part of the DSA if you want.
>
> We're all quite busy with updates for free packages. I'd recommend
> instead to include the update in the r2 Sarge stable update scheduled
> for next week. You can contact the stable release managers through
> [EMAIL PROTECTED]
Here is the point: there is a security flaw in xmame package
(non-free), which could lead to a privilege escalation (some xmame-*
packages are installed setuid root). As Moritz said they are already
quite busy with free packages, so I would like to know if it is possible
to include the fix in 3.1r2 (maybe it is a little late now?).
Attached is my patch to Sarge version of xmame. Of course I would like
the maintainer to give his opinion about it. Bruno?
Regards,
Pierre Riteau
--- xmame-0.86.orig/src/unix/dirio.c
+++ xmame-0.86/src/unix/dirio.c
@@ -184,7 +184,7 @@
#else
getcwd(cwd, MAXPATHL);
#endif
- strcat(cwd, "/");
+ strncat(cwd, "/", sizeof(cwd) - strlen(cwd) - 1);
return cwd;
}
--- xmame-0.86.orig/src/unix/fileio.c
+++ xmame-0.86/src/unix/fileio.c
@@ -412,7 +412,7 @@
/* compose_path */
/* */
-static void compose_path(char *output, int pathtype, int pathindex, const char
*filename)
+static void compose_path(char *output, size_t outputlen, int pathtype, int
pathindex, const char *filename)
{
const char *basepath = get_path_for_filetype(pathtype, pathindex, NULL);
char *p;
@@ -425,10 +425,10 @@
/* compose the full path */
*output = 0;
if (basepath)
- strcat(output, basepath);
+ strncat(output, basepath, outputlen - strlen(output) - 1);
if (*output && !is_pathsep(output[strlen(output) - 1]))
- strcat(output, "/");
- strcat(output, filename);
+ strncat(output, "/", outputlen - strlen(output) - 1);
+ strncat(output, filename, outputlen - strlen(output) - 1);
/* convert backslashes to forward slashes */
for (p = output; *p; p++)
@@ -463,7 +463,7 @@
char fullpath[1024];
/* compose the full path */
- compose_path(fullpath, pathtype, pathindex, filename);
+ compose_path(fullpath, sizeof(fullpath), pathtype, pathindex, filename);
/* get the file attributes */
if (stat(fullpath, &buf))
@@ -499,7 +499,7 @@
memset(file, 0, sizeof(*file));
/* compose the full path */
- compose_path(fullpath, pathtype, pathindex, filename);
+ compose_path(fullpath, sizeof(fullpath), pathtype, pathindex, filename);
/* attempt to open the file */
file->fileptr = fopen(fullpath, mode);
@@ -699,7 +699,7 @@
char fullpath[1024];
/* compose the full path */
- compose_path(fullpath, pathtype, pathindex, dirname);
+ compose_path(fullpath, sizeof(fullpath), pathtype, pathindex, dirname);
return check_and_create_dir(fullpath) ? 0 : 1;
}
--- xmame-0.86.orig/src/unix/joystick-drivers/joy_i386.c
+++ xmame-0.86/src/unix/joystick-drivers/joy_i386.c
@@ -83,7 +83,7 @@
fprintf (stderr_file, "I386 joystick interface initialization...\n");
for (i = first_dev; i <= last_dev; i++)
{
- sprintf (devname, "%s%d", joy_dev, i);
+ snprintf (devname, sizeof(devname), "%s%d", joy_dev, i);
if ((joy_data[i].fd = open (devname, O_RDONLY)) >= 0)
{
if(joytype != JOY_I386NEW)
--- xmame-0.86.orig/src/unix/config.c
+++ xmame-0.86/src/unix/config.c
@@ -627,7 +627,7 @@
INP_HEADER inp_header;
memset(&inp_header, '\0', sizeof(INP_HEADER));
- strcpy(inp_header.name, drivers[game_index]->name);
+ strncpy(inp_header.name, drivers[game_index]->name,
sizeof(inp_header.name) - 1);
mame_fwrite(options.record, &inp_header, sizeof(INP_HEADER));
}
--- xmame-0.86.orig/src/fileio.c
+++ xmame-0.86/src/fileio.c
@@ -325,16 +325,20 @@
int pathindex;
/* copy the filename and add an extension */
- strcpy(modified_filename, filename);
+ strncpy(modified_filename, filename, sizeof(modified_filename) - 1);
+ modified_filename[sizeof(modified_filename) - 1] = 0;
if (extension)
{
char *p = strchr(modified_filename, '.');
if (p)
- strcpy(p, extension);
+ {
+ strncpy(p, extension, si
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
Pierre Riteau wrote: > On Wed, Apr 05, 2006 at 11:00:16AM +0200, Moritz Muehlenhoff wrote: > > x11 isn't setuid at all. -sdl has a strong debconf warning, that setuid > > root is a risk (I guess it's used for DGA?) and the user can select it. > > Only svgalib is setuid root, but a system running svgalib apps in the year > > 2006 is lost security-wise anyway. We should rather get rid of it completely > > for Etch. > > I think it is the opposite. -sdl is not installed setuid root, whereas > -x11 ask the user if he want to install setuid to use DGA extension. I might have mixed that up. > The Debian security FAQ says that non-free is not supported, and I > understand why. But it also says that if it is fixable, an update can be > made. There were (a few) non-free security updates in the past. > > I see that Bruno is alive :) If he reviews my patch for Sarge and if the > security buildds have CPU time available, is it possible to release an > update? I can write a part of the DSA if you want. We're all quite busy with updates for free packages. I'd recommend instead to include the update in the r2 Sarge stable update scheduled for next week. You can contact the stable release managers through [EMAIL PROTECTED] Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
On Wed, Apr 05, 2006 at 11:00:16AM +0200, Moritz Muehlenhoff wrote: > x11 isn't setuid at all. -sdl has a strong debconf warning, that setuid > root is a risk (I guess it's used for DGA?) and the user can select it. > Only svgalib is setuid root, but a system running svgalib apps in the year > 2006 is lost security-wise anyway. We should rather get rid of it completely > for Etch. I think it is the opposite. -sdl is not installed setuid root, whereas -x11 ask the user if he want to install setuid to use DGA extension. But the default answer is yes. -svga is always installed setuid root. The Debian security FAQ says that non-free is not supported, and I understand why. But it also says that if it is fixable, an update can be made. There were (a few) non-free security updates in the past. I see that Bruno is alive :) If he reviews my patch for Sarge and if the security buildds have CPU time available, is it possible to release an update? I can write a part of the DSA if you want. Regards, Pierre Riteau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
On Wed, 2006-04-05 at 11:22 +0200, Moritz Muehlenhoff wrote: > Steve Langasek wrote: > > On Wed, Apr 05, 2006 at 11:00:16AM +0200, Moritz Muehlenhoff wrote: > > > Steve Langasek wrote: > > > > > > This bug has been pending for more than two months and no fix in > > > > > > Debian > > > > > > yet... Does Bruno still track his bugs? > > > > > > > > Here is two patches for both Sarge and Sid versions. > > > > > > > > Pierre Riteau > > > > > > > > (CC'ing [EMAIL PROTECTED] for the stable fix, and the > > > > > > Co-Maintainer as I don't know if he receives BTS replies) > > > > > > (Email address in previous message for tagging is wrong, I was > > > > > > playing > > > > > > with bts thinking it wouldn't commit the changes) > > > > > > > Xmame is non-free and thus not supported by the Security Team. > > > > > (Only the relatively obscure -svgalib version is affected, anyway.) > > > > > > Is it the case that this bug doesn't affect the other frontends *at > > > > all*, or > > > > just that, not being suid root, it's just an arbitrary code execution > > > > bug > > > > instead of a root exploit? > > > > > It's a local vulnerability, the only security ramification would be a > > > privilege escalation: > > > > If untrusted input can trigger arbitrary code execution, then that still has > > security implications. I don't think that most users only use trusted ROMs > > with xmame. :) > > Yeah, but according to the original advisory the overflows are in args > parsing. > (It could be possible that these values can somehow be influenced from a > crafted > ROM, though.) > > Cheers, > Moritz > Hi, Sorry for the delay in this reply. Timeline: 26 Mar 2006: I submitted a NEW package (xmame-1.0.4) with xmess-SDL. Sun, 02 Apr 2006: xmame_0.104-1_i386.changes REJECTED (Due to a minor mistake) Sun, 02 Apr 2006: xmame_0.104-1_i386.changes is NEW (Fixed the mistake and uploaded the new package). Changelog: * New upstream release. * Fixed exploitable buffer overflows [CVE-2006-0176]. (closes: #349653) * Added xmess-sdl binary package. (closes: #340460) Announcing to debian-devel-changes@lists.debian.org Closing bugs: 340460 349653 So, please be patient. Thanks, Bruno. -- "In this life, we are Kings or Pawns. Emperors or Fools." signature.asc Description: This is a digitally signed message part
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
Steve Langasek wrote: > On Wed, Apr 05, 2006 at 11:00:16AM +0200, Moritz Muehlenhoff wrote: > > Steve Langasek wrote: > > > > > This bug has been pending for more than two months and no fix in > > > > > Debian > > > > > yet... Does Bruno still track his bugs? > > > > > > Here is two patches for both Sarge and Sid versions. > > > > > > Pierre Riteau > > > > > > (CC'ing [EMAIL PROTECTED] for the stable fix, and the > > > > > Co-Maintainer as I don't know if he receives BTS replies) > > > > > (Email address in previous message for tagging is wrong, I was playing > > > > > with bts thinking it wouldn't commit the changes) > > > > > Xmame is non-free and thus not supported by the Security Team. > > > > (Only the relatively obscure -svgalib version is affected, anyway.) > > > > Is it the case that this bug doesn't affect the other frontends *at all*, > > > or > > > just that, not being suid root, it's just an arbitrary code execution bug > > > instead of a root exploit? > > > It's a local vulnerability, the only security ramification would be a > > privilege escalation: > > If untrusted input can trigger arbitrary code execution, then that still has > security implications. I don't think that most users only use trusted ROMs > with xmame. :) Yeah, but according to the original advisory the overflows are in args parsing. (It could be possible that these values can somehow be influenced from a crafted ROM, though.) Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
On Wed, Apr 05, 2006 at 11:00:16AM +0200, Moritz Muehlenhoff wrote: > Steve Langasek wrote: > > > > This bug has been pending for more than two months and no fix in Debian > > > > yet... Does Bruno still track his bugs? > > > > Here is two patches for both Sarge and Sid versions. > > > > Pierre Riteau > > > > (CC'ing [EMAIL PROTECTED] for the stable fix, and the > > > > Co-Maintainer as I don't know if he receives BTS replies) > > > > (Email address in previous message for tagging is wrong, I was playing > > > > with bts thinking it wouldn't commit the changes) > > > Xmame is non-free and thus not supported by the Security Team. > > > (Only the relatively obscure -svgalib version is affected, anyway.) > > Is it the case that this bug doesn't affect the other frontends *at all*, or > > just that, not being suid root, it's just an arbitrary code execution bug > > instead of a root exploit? > It's a local vulnerability, the only security ramification would be a > privilege escalation: If untrusted input can trigger arbitrary code execution, then that still has security implications. I don't think that most users only use trusted ROMs with xmame. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
Steve Langasek wrote: > > > This bug has been pending for more than two months and no fix in Debian > > > yet... Does Bruno still track his bugs? > > > > Here is two patches for both Sarge and Sid versions. > > > > Pierre Riteau > > > > (CC'ing [EMAIL PROTECTED] for the stable fix, and the > > > Co-Maintainer as I don't know if he receives BTS replies) > > > (Email address in previous message for tagging is wrong, I was playing > > > with bts thinking it wouldn't commit the changes) > > > Xmame is non-free and thus not supported by the Security Team. > > (Only the relatively obscure -svgalib version is affected, anyway.) > > Is it the case that this bug doesn't affect the other frontends *at all*, or > just that, not being suid root, it's just an arbitrary code execution bug > instead of a root exploit? It's a local vulnerability, the only security ramification would be a privilege escalation: x11 isn't setuid at all. -sdl has a strong debconf warning, that setuid root is a risk (I guess it's used for DGA?) and the user can select it. Only svgalib is setuid root, but a system running svgalib apps in the year 2006 is lost security-wise anyway. We should rather get rid of it completely for Etch. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
On Wed, Apr 05, 2006 at 10:08:55AM +0200, Moritz Muehlenhoff wrote: > On Tue, Apr 04, 2006 at 02:56:21PM +0200, Pierre Riteau wrote: > > This bug has been pending for more than two months and no fix in Debian > > yet... Does Bruno still track his bugs? > > Here is two patches for both Sarge and Sid versions. > > Pierre Riteau > > (CC'ing [EMAIL PROTECTED] for the stable fix, and the > > Co-Maintainer as I don't know if he receives BTS replies) > > (Email address in previous message for tagging is wrong, I was playing > > with bts thinking it wouldn't commit the changes) > Xmame is non-free and thus not supported by the Security Team. > (Only the relatively obscure -svgalib version is affected, anyway.) Is it the case that this bug doesn't affect the other frontends *at all*, or just that, not being suid root, it's just an arbitrary code execution bug instead of a root exploit? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
On Tue, Apr 04, 2006 at 02:56:21PM +0200, Pierre Riteau wrote: > This bug has been pending for more than two months and no fix in Debian > yet... Does Bruno still track his bugs? > > Here is two patches for both Sarge and Sid versions. > > Pierre Riteau > > (CC'ing [EMAIL PROTECTED] for the stable fix, and the > Co-Maintainer as I don't know if he receives BTS replies) > (Email address in previous message for tagging is wrong, I was playing > with bts thinking it wouldn't commit the changes) Xmame is non-free and thus not supported by the Security Team. (Only the relatively obscure -svgalib version is affected, anyway.) Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349653: xmame: exploitable buffer overflows [CVE-2006-0176]
This bug has been pending for more than two months and no fix in Debian
yet... Does Bruno still track his bugs?
Here is two patches for both Sarge and Sid versions.
Pierre Riteau
(CC'ing [EMAIL PROTECTED] for the stable fix, and the
Co-Maintainer as I don't know if he receives BTS replies)
(Email address in previous message for tagging is wrong, I was playing
with bts thinking it wouldn't commit the changes)
--- xmame-0.86.orig/src/unix/dirio.c
+++ xmame-0.86/src/unix/dirio.c
@@ -184,7 +184,7 @@
#else
getcwd(cwd, MAXPATHL);
#endif
- strcat(cwd, "/");
+ strncat(cwd, "/", sizeof(cwd) - strlen(cwd) - 1);
return cwd;
}
--- xmame-0.86.orig/src/unix/fileio.c
+++ xmame-0.86/src/unix/fileio.c
@@ -412,7 +412,7 @@
/* compose_path */
/* */
-static void compose_path(char *output, int pathtype, int pathindex, const char
*filename)
+static void compose_path(char *output, size_t outputlen, int pathtype, int
pathindex, const char *filename)
{
const char *basepath = get_path_for_filetype(pathtype, pathindex, NULL);
char *p;
@@ -425,10 +425,10 @@
/* compose the full path */
*output = 0;
if (basepath)
- strcat(output, basepath);
+ strncat(output, basepath, outputlen - strlen(output) - 1);
if (*output && !is_pathsep(output[strlen(output) - 1]))
- strcat(output, "/");
- strcat(output, filename);
+ strncat(output, "/", outputlen - strlen(output) - 1);
+ strncat(output, filename, outputlen - strlen(output) - 1);
/* convert backslashes to forward slashes */
for (p = output; *p; p++)
@@ -463,7 +463,7 @@
char fullpath[1024];
/* compose the full path */
- compose_path(fullpath, pathtype, pathindex, filename);
+ compose_path(fullpath, sizeof(fullpath), pathtype, pathindex, filename);
/* get the file attributes */
if (stat(fullpath, &buf))
@@ -499,7 +499,7 @@
memset(file, 0, sizeof(*file));
/* compose the full path */
- compose_path(fullpath, pathtype, pathindex, filename);
+ compose_path(fullpath, sizeof(fullpath), pathtype, pathindex, filename);
/* attempt to open the file */
file->fileptr = fopen(fullpath, mode);
@@ -699,7 +699,7 @@
char fullpath[1024];
/* compose the full path */
- compose_path(fullpath, pathtype, pathindex, dirname);
+ compose_path(fullpath, sizeof(fullpath), pathtype, pathindex, dirname);
return check_and_create_dir(fullpath) ? 0 : 1;
}
--- xmame-0.86.orig/src/unix/joystick-drivers/joy_i386.c
+++ xmame-0.86/src/unix/joystick-drivers/joy_i386.c
@@ -83,7 +83,7 @@
fprintf (stderr_file, "I386 joystick interface initialization...\n");
for (i = first_dev; i <= last_dev; i++)
{
- sprintf (devname, "%s%d", joy_dev, i);
+ snprintf (devname, sizeof(devname), "%s%d", joy_dev, i);
if ((joy_data[i].fd = open (devname, O_RDONLY)) >= 0)
{
if(joytype != JOY_I386NEW)
--- xmame-0.86.orig/src/unix/config.c
+++ xmame-0.86/src/unix/config.c
@@ -627,7 +627,7 @@
INP_HEADER inp_header;
memset(&inp_header, '\0', sizeof(INP_HEADER));
- strcpy(inp_header.name, drivers[game_index]->name);
+ strncpy(inp_header.name, drivers[game_index]->name,
sizeof(inp_header.name) - 1);
mame_fwrite(options.record, &inp_header, sizeof(INP_HEADER));
}
--- xmame-0.86.orig/src/fileio.c
+++ xmame-0.86/src/fileio.c
@@ -325,16 +325,20 @@
int pathindex;
/* copy the filename and add an extension */
- strcpy(modified_filename, filename);
+ strncpy(modified_filename, filename, sizeof(modified_filename) - 1);
+ modified_filename[sizeof(modified_filename) - 1] = 0;
if (extension)
{
char *p = strchr(modified_filename, '.');
if (p)
- strcpy(p, extension);
+ {
+ strncpy(p, extension, sizeof(modified_filename) - (p -
modified_filename) - 1);
+ modified_filename[sizeof(modified_filename) - 1] = 0;
+ }
else
{
- strcat(modified_filename, ".");
- strcat(modified_filename, extension);
+ strncat(modified_filename, ".",
sizeof(modified_filename) - strlen(modified_filename) - 1);
+ strncat(modified_filename, extension,
sizeof(modified_filename) - strlen(modified_filename) - 1);
}
}
@@ -344,19 +348,19 @@
char name[256];
/* first check the raw filename, in case we're looking for a
directory */
- sprintf(name, "%s", filename);
+ snprin
