CVE-2018-0492

[MarkusTeufelberger]

Just a short heads-up:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-0492

[s7726]

The package listed at this URL appears to contain a patch that resolves the vulnerability.
https://packages.ubuntu.com/source/bionic/beep

Going straight to the debian package that fixed it did not have a patch, just a diff, so I figured this would be a quicker find/implementation.

[MarkusTeufelberger]

The diff seems to be this one:

diff --git a/beep.c b/beep.c
index 7da2e70..4323d31 100644
--- a/beep.c
+++ b/beep.c
@@ -109,6 +109,7 @@ void do_beep(int freq) {
      /* BEEP_TYPE_EVDEV */
      struct input_event e;
 
+     memset(&e, 0, sizeof(e));
      e.type = EV_SND;
      e.code = SND_TONE;
      e.value = freq;
@@ -124,10 +125,6 @@ void do_beep(int freq) {
 /* If we get interrupted, it would be nice to not leave the speaker beeping in
    perpetuity. */
 void handle_signal(int signum) {
-
-  if(console_device)
-    free(console_device);
-
   switch(signum) {
   case SIGINT:
   case SIGTERM:
@@ -257,7 +254,7 @@ void parse_command_line(int argc, char **argv, beep_parms_t *result) {
       result->verbose = 1;
       break;
     case 'e' : /* also --device */
-      console_device = strdup(optarg);
+      console_device = optarg;
       break;
     case 'h' : /* notice that this is also --help */
     default :
@@ -276,26 +273,6 @@ void play_beep(beep_parms_t parms) {
 	"%d delay after) @ %.2f Hz\n",
 	parms.reps, parms.length, parms.delay, parms.end_delay, parms.freq);
 
-  /* try to snag the console */
-  if(console_device)
-    console_fd = open(console_device, O_WRONLY);
-  else
-    if((console_fd = open("/dev/tty0", O_WRONLY)) == -1)
-      console_fd = open("/dev/vc/0", O_WRONLY);
-
-  if(console_fd == -1) {
-    fprintf(stderr, "Could not open %s for writing\n",
-      console_device != NULL ? console_device : "/dev/tty0 or /dev/vc/0");
-    printf("\a");  /* Output the only beep we can, in an effort to fall back on usefulness */
-    perror("open");
-    exit(1);
-  }
-
-  if (ioctl(console_fd, EVIOCGSND(0)) != -1)
-    console_type = BEEP_TYPE_EVDEV;
-  else
-    console_type = BEEP_TYPE_CONSOLE;
-  
   /* Beep */
   for (i = 0; i < parms.reps; i++) {                    /* start beep */
     do_beep(parms.freq);
@@ -305,8 +282,6 @@ void play_beep(beep_parms_t parms) {
     if(parms.end_delay || (i+1 < parms.reps))
        usleep(1000*parms.delay);                        /* wait...    */
   }                                                     /* repeat.    */
-
-  close(console_fd);
 }
 
 
@@ -328,6 +303,26 @@ int main(int argc, char **argv) {
   signal(SIGTERM, handle_signal);
   parse_command_line(argc, argv, parms);
 
+  /* try to snag the console */
+  if(console_device)
+    console_fd = open(console_device, O_WRONLY);
+  else
+    if((console_fd = open("/dev/tty0", O_WRONLY)) == -1)
+      console_fd = open("/dev/vc/0", O_WRONLY);
+
+  if(console_fd == -1) {
+    fprintf(stderr, "Could not open %s for writing\n",
+      console_device != NULL ? console_device : "/dev/tty0 or /dev/vc/0");
+    printf("\a");  /* Output the only beep we can, in an effort to fall back on usefulness */
+    perror("open");
+    exit(1);
+  }
+
+  if (ioctl(console_fd, EVIOCGSND(0)) != -1)
+    console_type = BEEP_TYPE_EVDEV;
+  else
+    console_type = BEEP_TYPE_CONSOLE;
+
   /* this outermost while loop handles the possibility that -n/--new has been
      used, i.e. that we have multiple beeps specified. Each iteration will
      play, then free() one parms instance. */
@@ -365,8 +360,8 @@ int main(int argc, char **argv) {
     parms = next;
   }
 
-  if(console_device)
-    free(console_device);
+  close(console_fd);
+  console_fd = -1;
 
   return EXIT_SUCCESS;
 }

...still a bit weird that Debian/Ubuntu fix stuff without opening PRs here. Hopefully they contacted the author in private at least.

[s7726]

Ubuntu actually had an additional patch as well that covered handling one of the system SIGNALs.
Upstreaming is for chumps ;)

[Nicals]

There is no activity on this Github account since June 2016, and no activity on this particular repository since 2013. I don't think this is the place to fix the code...

[markand]

I wonder if people will understand that free accept null pointers as well.

[Stargateur]

I don't understand where does this race condition come from, ioctl ?

The code of this program is ugly and the memset of this patch is ugly too and the choice to not duplicate stdarg come from nowhere.

Oh maybe the free in the signal handler ? In this case, why move "/* try to snag the console */" block code ?

[MarkusTeufelberger]

There is no activity on this Github account since June 2016, and no activity on this particular repository since 2013. I don't think this is the place to fix the code...

Where else would it be? Debian/Ubuntu lists http://johnath.com/beep/ as upstream and that page links to this repository.

At the very least, the patches by Debian/Ubuntu should have been submitted as pull requests.

[LangerJan]

Just my 2 cents and pure speculation:

Oh maybe the free in the signal handler ?

Since it is stated that this is a race condition, it has to do with the signal handler - no other race to see here. Therefore, we have a use-after-free situation with console_device here.

In this case, why move "/* try to snag the console */" block code ?

In order to not having a multiple use-after-free of console_device.

[Stargateur]

The signal handler don't call play_beep(), so there is no use-after-free of console_device. (expect the multiple possible free() of the same pointer witch of course is fatal)

[LangerJan]

Maybe it has to do with calling free() inside the signal handler, which is not considered an async-signal-safe function.

[s7726]

The report says it's an issue when privilege escalated, so just thinking in the context of normal execution isn't enough.

…

On Wed, Apr 4, 2018, 7:22 AM LangerJan ***@***.***> wrote: Maybe it has to do with calling free() inside the signal handler, which is not considered an async-signal-safe function. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDnWSgDR72weEQk4Tbl1aRQ-1699YD0ks5tlNcOgaJpZM4TE6O7> .

[zb3]

I think the exploit could have a great educational value here.

EDIT: ioctl is not async-signal-safe either, but it's still called in patched version.

[rain-1]

It's possible that there is no actual priv esc. I will try to reach out to lamb.

[LangerJan]

Here is an interesting article which explained the problem to me: http://lcamtuf.coredump.cx/signals.txt
In short:

• Using free() inside a signal handler is a bad idea. Its not an async-signal-safe function (see man 7 signal-safety on that). It could be interrupted with another signal, causing destruction of global structures/variables of the heap management.
• The current version of beep.c here handles two signals (SIGINT and SIGTERM) in one handler function, which makes it possible to re-enter handle_signal() while it's running, allowing for a double free.