Hi Kay!
(Trying to move this to the hal list, where it actually belongs to.)
Kay Sievers [2006-01-12 13:15 +0100]:
> > We had this discussion several times ([1] is the last one known to
> > me), and it seems that neither side can convince the other, so I do
> > not see a point of these snide statements.
>
> And we still expect your explanation of the attack vector. You _never_
> answered this, and we asked you several times for it.
That's not true, I did several times. Let me quote from the reference
I gave:
Since so many applications talk to hal, there are lots of them: dbus
messages with specially crafted strings (buffer overflows),
exploiting race conditions or special hardware to leave certain
fields uninitialized (NULL dereference), specially crafted USB
sticks that cause crashes in the file system/partition detection
code, exploiting race conditions to hang hal, etc.
The point is that we had these kind of bugs in the past, and I'm
absolutely certain that there will be more bugs in the future.
If you want a concrete example: I just grepped for 'alloc' and found a
standard integer overflow in volume_id/mac.c:
volume_id_probe_mac_partition_map():
buf = volume_id_get_buffer(id, off + bsize, 0x200);
[...]
part = (struct mac_partition *) buf;
[...
part_count = be32_to_cpu(part->map_count);
[...]
id->partitions =
malloc(part_count * sizeof(struct volume_id_partition));
so it seems that e. g. an USB stick with a specially crafted mac
partition table (with a negative or large partition count) would
trigger an integer overflow in the multiplication, which leads to a
wrong memory allocation. There are no sanity checks for part_count.
This is just one example of dangerous code. I didn't thoroughly check
the issue; there might be side effects that make it non-exploitable,
but even if that is the case for this particular bug, you can't always
count on your luck.
> > (Also, it's not only Ubuntu; Debian has it, too, and running it
> > unprivileged is even the upstream default up to now.)
>
> Sure, that will probably change cause Red Hat and Novell don't use it
> and do almost all development there. You can keep that as a out-of-tree
> patch on-top.
Sure; I'd prefer a common solution for all vendors, but keeping it as
a separate debian/ubuntu patch is easy enough (I wrote it in the first
place, so I shouldn't have troubles).
> > FWIW, I would happily accept the privilege separation architecture
> > that was planned long ago. Matthew Garret and I talked about this
> > yesterday, and I hope that I can find some time to actually implement
> > it.
>
> Nice, but please explain in detail the benefit of such an architecture,
> with the current attack vectors and how such a change would solve it.
In Debian and Ubuntu, hald runs as an unprivileged normal user with
some added groups (cdrom and plugdev), which means that it can read
CD-ROMs and USB/FireWire devices. I. e. even if an attacker manages to
execute arbitrary code in hald, he can scramble the database and
trigger wrong messages to hald clients (like g-v-m), but the attacker
can never escalate his privileges to run code as root or as the target
user.
In the architecture mentioned above (which David proposed long ago,
BTW), privilege separation is a bit weaker, but still acceptable: the
worst an attacker who breaks hald can do is to execute a predefined
callout with root privileges, i. e. do things like mounting/unmounting
drives for an user or suspend the machine. That's consideraby worse
than what we have in Debian/Ubuntu now, but still a lot less than
complete root privilege escalation.
OTOH, with hald running as root, every buffer overflow can potentially
immediately be exploited to execute arbitrary code as root. Just
because 99% of the hald code run with privileges it doesn't need.
If your aim is to provide a generally usable hardware abstraction
client, then you just need to think about a sane security
archtitecture as well; completely neglecting the topic will not help
to increase the trust people put into hal. I am happy to go through
the discussion and help with improving hald, but only if there is
actually some interest from upstream's side.
> > (who still does not understand why everybody else seems to ignore
> > dbus' wonderful way of separating privileges with dbus services and
> > instead uses the old centralized daemon way.)
>
> Yeah, "explain" instead of "wondering", and contribute stuff to solve
> actual problems instead of insisting on feature crippling, for no
> visible reason.
Both parts are wrong, please try to stick to the facts; there is no
point in getting angry or personal. I did not insult you, and I don't
want to start a flamewar here.
You are of course free to think that security is not an actual problem
for hal. But in a distribution that is supported for several years we
just have to worry about it.
I contributed the hal derooting patch, I contributed pmount which was
audited by several people and provides clean privilege separation, I
did all necessary changes to provide all features hal has to offer
with a much more sane security architecture. There is no feature
crippling. (I contributed several bug fixes as well, btw. It's not
that I just complain, but I just get a bit sick of discussing this
particular topic over and over again.)
Thanks for considering, and have a nice day,
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
Attachment:
signature.asc
Description: Digital signature