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 [EMAIL PROTECTED] (full text, mbox):
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] (full text, mbox):
From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Roland McGrath <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Roland McGrath <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Roland McGrath <[EMAIL PROTECTED]>
To: Marcus Brinkmann <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: Roland McGrath <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: Florian Weimer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] (full text, mbox):
From: "Alfred M\. Szmidt" <[EMAIL PROTECTED]>
To: Florian Weimer <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], 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/
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
