bugtraq - Re: Sun M-class hardware denial of service

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080930152313.GA28556@bofh.cns.ualberta.ca>
Date: Tue, 30 Sep 2008 09:23:13 -0600
From: Bob Beck <beck@...berta.ca>
To: Brett Lymn <blymn@...systems.com.au>
Cc: Theo de Raadt <deraadt@....openbsd.org>,
	Florian Weimer <fw@...eb.enyo.de>,
	B 650 <dunc.on.usenet@...glemail.com>, bugtraq@...urityfocus.com
Subject: Re: Sun M-class hardware denial of service

> Not really - what I am not doing is trying to beat up a firmware
> problem that whilst being quite bad can be mitigated by using native
> features of Solaris.  Too bad if OpenBSD cannot do the same - I am not
> really sure about the benefits of OpenBSD on that scale of hardware
> anyway considering the lack of kernel threading and the parlous state
> of userland threading.

	I don't think you get it. OpenBSD doesn't care a whit about
this. They stumbled upon it as the result of bringing up OpenBSD on
such a machine. No - currently I wouldn't run OpenBSD on an M-class
box either, other than for development purposes. but that's not really
the point is it. Nobody except you is saying this problem has anything
to do with running OpenBSD on a machine.

	The point is anyone with a black hat with sufficient clue enough to
ignore this sort of ass-covering nonsense and write a kernel module,
and go look at what the OpenBSD kernel *does* to wedge the zone, and
make a solaris kernel module that does the same. At which point, at a
minimum, the same wedging becomes possible from solaris, so yes, this
is breaking separation. 

	You're saying "well golly gee, but it's still separation if you don't
let the attacker load kernel modules." good on you. have fun with your
attacker, may you meet one of competence level greater than a script
kiddie someday. I have, they're nice guys. and smart. smarter than me
in a lot of things :) Personally if I'm buying gear to drink the whole
virtualization kool-aid - the kool-aid has to work - meaning stuff done
in the guest OS should never be able to do stuff like this.

	-Bob