[bug #15295] Mach lets processes write to I/O ports

[Samuel Thibault]

URL:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15295>

                 Summary: Mach lets processes write to I/O ports
                 Project: The GNU Hurd
            Submitted by: sthibaul
            Submitted on: lun 26.12.2005 à 22:23
                Category: GNU Mach
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Hardware Support
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Reproducibility: Every Time
              Size (loc): None
                  Effort: 0.00

    _______________________________________________________

Details:

Message received at submit@bugs.debian.org (full text, mbox):

From: Kalle Olavi Niemitalo <tosi@ees2.oulu.fi>
To: submit@bugs.debian.org
Subject: Mach lets processes write to I/O ports
Date: 05 Oct 1999 21:14:38 +0300

Package: gnumach
Version: 1:1.2-1.kn.1
Severity: normal

(The version was 1:1.2-1 before I applied my Alt Gr patch and
disabled almost all devices.)

Roland McGrath <roland@frob.com> writes:

> > I then
> > removed the call, but the program could still write to the ports.
> > So maybe it's automatic after all.
>
> Hmm, it shouldn't be.  It would be good if someone could look into this
> (maybe you can get a test case together and file a BTS report?), but I'm
> not going to worry about it for now.

So, here is the report.

The following program should not work.  Mach shouldn't let
processes read or write I/O ports unless they have explicitly
asked for permission.  But the program works.  Worse, it doesn't
even require root privileges.

see ../util.h and ioport.c


Message received at 46709@bugs.debian.org (full text, mbox):

From: Kalle Olavi Niemitalo <kon@iki.fi>
To: 46709@bugs.debian.org
Subject: Re: Mach lets processes write to I/O ports
Date: 03 May 2001 11:53:41 +0300

tags 46709 security
severity 46709 critical
quit

Letting processes write to EGA ports isn't that awful (with
today's sync-protected monitors), but if Mach also lets them
write to ports used by IDE or SCSI, then it "introduces a
security hole on systems where you install the package."

No, I didn't really test whether Mach allows that -- I don't know
enough about IDE to do that in a way that won't hurt my data.
However, I think it's very likely.  Please show I'm mistaken.

This would be a local attack, but might not require any UIDs.



Message received at 46709@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>, 46709@bugs.debian.org
Subject: Re: Bug#46709: Mach lets processes write to I/O ports
Date: Sun, 7 Oct 2001 05:19:28 +0200

[Message part 1 (text/plain, inline)]

On Thu, May 03, 2001 at 11:53:41AM +0300, Kalle Olavi Niemitalo wrote:
> Letting processes write to EGA ports isn't that awful (with
> today's sync-protected monitors), but if Mach also lets them
> write to ports used by IDE or SCSI, then it "introduces a
> security hole on systems where you install the package."

I have found the bugs that allow users to write to I/O ports without
requesting permission.  In i386/i386/ktss.c, only the last byte of the
io map of the KERNEL_TSS is set to 0xff (access forbidden), all other
are left as they are (all zeros? random? I don't know, but suspect all
zero).  Threads that don't have their own TSS use the KERNEL_TSS, and
this means all threads by default (see pcb.c).  BTW, I am pretty sure there
is an off by one error, which means that the code writes into the byte past
the bitmap, rather than the last byte of it (I verified that the bitmap
indeed starts at ktss, and that means that ktss + 0x10000/8 is off by one).

This is the first bug.  The second bug is that the i386_io_port_add function
that creates the user tss initializes it with access_all being true, which
means that it is initialized to all zero.  So a thread requesting any access
will always get all (I suspect).  The two places marked with /* XXX */ in
the iopb.c file seem to indicate that this is first a correct interpretation
of the code and that the author knew that this had to be fixed.  Replacing
the
TRUE at the XXX with FALSE, and setting all bytes in the map to 0xff in the
KERNEL_TSS should fix this, but I did not test that part.

The reason I could not continue testing the user tss is that
the i386_io_port_add call can't find the device -> io_port mapping.  I tried
both the kd and iopl device, and neither worked.  This requires more
debugging (maybe tomorrow).  We decided by now that this is the wrong
approach
anyway, and that all this code is doomed to be replaced by a somewhat
different approach.  However, I think it is not a bad idea to fix this,
especially as it doesn't seem to hard, before going on and messing with it
(well, at least for me as I have to learn more details about the tss stuff
first before I can have a go at the new interface).

I am including my preliminary patch and my two test programs (incomplete,
just for reference) that show the i386_io_port_add problem.  The test
program you submitted fails with Illegal Instruction if you apply my patch.

BTW, I noticed that there are reminiscences of io map support in
thread_setstatus and thread_getstatus, with a reference to a
i386_io_port_map
call that seems to be intended to set/get a complete bitmask.  This cruft
can
be cleaned up when we have a go at the new interface.

Thanks,
Marcus

See patch1, ioport2.c and ioport3.c

Message received at 46709@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>, 46709@bugs.debian.org
Subject: Re: Bug#46709: Mach lets processes write to I/O ports
Date: Sun, 7 Oct 2001 15:20:11 +0200

On Sun, Oct 07, 2001 at 05:19:28AM +0200, Marcus Brinkmann wrote:
> The reason I could not continue testing the user tss is that
> the i386_io_port_add call can't find the device -> io_port mapping.

It turns out that the mach_device_t address registered with io_port_create
doesn't match the mach_device_t address used to lookup the device again.
I don't know why (yet).

Thanks,
Marcus

Message received at 46709@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>, 46709@bugs.debian.org
Subject: Re: Bug#46709: Mach lets processes write to I/O ports
Date: Sun, 7 Oct 2001 19:11:01 +0200

On Sun, Oct 07, 2001 at 03:20:11PM +0200, Marcus Brinkmann wrote:
> On Sun, Oct 07, 2001 at 05:19:28AM +0200, Marcus Brinkmann wrote:
> > The reason I could not continue testing the user tss is that
> > the i386_io_port_add call can't find the device -> io_port mapping.
>
> It turns out that the mach_device_t address registered with io_port_create
> doesn't match the mach_device_t address used to lookup the device again.
> I don't know why (yet).

The i386_io_port_add and i386_io_port_remove do not convert the device_t to
a mach_device_t as the other device RPCs for i386 (this is connected to the
glue code in i386/i386at/i386at_ds_routines.c, which is introduces another
level of indirection for device RPCs, without changing the io_port rpcs as
well).

I have fixed this, and i386_io_port_add finds the i/o port list now.
However, the I/O permission are not correctly updated, I still get an
Illegal Instruction exception.  So I am continuing to debug this.

The below patch is to only fix this particular problem.  It's as ugly as the
rest of the glue code :)

Thanks,
Marcus

See patch2

Message received at 46709@bugs.debian.org (full text, mbox):

From: Roland McGrath <roland@frob.com>
To: 46709@bugs.debian.org
Date: Sun,  7 Oct 2001 15:32:15 -0400 (EDT)

The 0xff byte after the bitmap is a terminator byte, check your Intel book
vol 1, section 9.5.2.  So that, at least, is not the bug you thought it
was.  Note that that extra byte is included in the calculation for the
segment descriptor limit (which is a limit, not a size, so it always has
-1).

Your fix is ok, though I would use memset (not that it matters for a
boot-time only thing).

According to my Intel book, the other solution is to have no io bitmap
space at all: missing bits are treated as disallowed if the bitmap is
shorter than 64k, down to 0.  So just changing the limit in the
fill_gdt_descriptor call to sizeof(ktss)-1 should do it too.
If that solution works, it seems preferable off hand.
(That is what you get from oskit's base_tss, which oskit-mach uses.)

Message received at 46709@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Roland McGrath <roland@frob.com>, 46709@bugs.debian.org
Subject: Re: Bug#46709: (no subject)
Date: Sun, 7 Oct 2001 22:20:48 +0200

On Sun, Oct 07, 2001 at 03:32:15PM -0400, Roland McGrath wrote:
> The 0xff byte after the bitmap is a terminator byte, check your Intel book
> vol 1, section 9.5.2.

Ah, that explains it.  I have seen the extra byte, and was wondering what I
missed.  I have the Intel books now (got them today), so I can read up more
about this stuff.

BTW, the user tss does not contain such a terminator, so I will add one.

> Your fix is ok, though I would use memset (not that it matters for a
> boot-time only thing).

Yes, of course that's better.

> According to my Intel book, the other solution is to have no io bitmap
> space at all: missing bits are treated as disallowed if the bitmap is
> shorter than 64k, down to 0.

It also should work to set the io bitmap base address to or beyond the
segment with the same effect.

Thanks,
Marcus

Message received at 46709@bugs.debian.org (full text, mbox):

From: Roland McGrath <frob@debian.org>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Cc: 46709@bugs.debian.org
Subject: Re: Bug#46709: (no subject)
Date: Sun,  7 Oct 2001 16:39:37 -0400 (EDT)

> On Sun, Oct 07, 2001 at 03:32:15PM -0400, Roland McGrath wrote:
> > The 0xff byte after the bitmap is a terminator byte, check your Intel
book
> > vol 1, section 9.5.2.
>
> Ah, that explains it.  I have seen the extra byte, and was wondering what
I
> missed.  I have the Intel books now (got them today), so I can read up
more
> about this stuff.
>
> BTW, the user tss does not contain such a terminator, so I will add one.
>
> > Your fix is ok, though I would use memset (not that it matters for a
> > boot-time only thing).
>
> Yes, of course that's better.
>
> > According to my Intel book, the other solution is to have no io bitmap
> > space at all: missing bits are treated as disallowed if the bitmap is
> > shorter than 64k, down to 0.
>
> It also should work to set the io bitmap base address to or beyond the
> segment with the same effect.

That's what I meant by the bitmap being shorter.  It spans from the
specific base address (and offset from the beginning of the tss) to the end
of the segment, so the segment consists of nothing but the tss when the
bitmap is empty.


Message received at 46709@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Roland McGrath <frob@debian.org>
Cc: 46709@bugs.debian.org
Subject: Re: Bug#46709: (no subject)
Date: Sun, 7 Oct 2001 22:41:31 +0200

On Sun, Oct 07, 2001 at 04:39:37PM -0400, Roland McGrath wrote:
(I said:)
> > BTW, the user tss does not contain such a terminator, so I will add one.

This is wrong, it's called barrier and is there.  I was just confused.

> > It also should work to set the io bitmap base address to or beyond the
> > segment with the same effect.
>
> That's what I meant by the bitmap being shorter.

Ok.

Thanks,
Marcus

Message received at 46709@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: 46709@bugs.debian.org
Subject: Bug status
Date: Sun, 30 Oct 2005 23:14:14 +0100

Is this security bug still open, after more than six years?

Message received at 46709@bugs.debian.org (full text, mbox):

From: "Alfred M\. Szmidt" <ams@gnu.org>
To: Florian Weimer <fw@deneb.enyo.de>, 46709@bugs.debian.org
Cc: 46709@bugs.debian.org, debian-bugs-dist@lists.debian.org,
debian-hurd@lists.debian.org
Subject: Re: Bug#46709: Bug status
Date: Sun, 30 Oct 2005 23:37:14 +0100

   Is this security bug still open, after more than six years?

Yes, but it doesn't belong in the Debian BTS.  It would be nice if
someone could file all these bug reports into the proper place,
http://sv.gnu.org/p/hurd.








    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15295>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/