Fwd: [oss-security] "I miss LSD", slides, paper and tools relating to finding UNIX system level vulnerabilities (as given at 44CON)

[Mark Kettenis]

> Date: Fri, 15 Nov 2013 02:16:19 -0500 (EST)
> From: Mouse <mouse at Rodents-Montreal.ORG>
> 
> > My understanding is that the new code, by passing shared memory
> > through fd is a lot better since [...]
> 
> In those respects, yes.  But it's worse in that it requires write
> access to a filesystem - a filesystem which supports mmap - with space
> enough to hold the shared memory segments, which MIT-SHM doesn't.

That's not really true.  POSIX defines interfaces to create and remove
shared memory objects: shm_open() and shm_unlink().  On most systems
these interfaces are just thin wrappers around open() and unlink()
that create files in a suitable location.  But a kernel implemantation
that isn't tied to a real filesystem is also possible.  And even the
wrapper approach at least abstracts away the knowledge about where to
put the files; a good implementation would probably use a dedicated
in-memory filesystem for this.

Keith mentioned the other day that he didn't use shm_open() because of
security concerns.  However shm_open()/shm_unlink() isn't inherently
less secure than using open()/unlink().  It's just that it is rather
easy to use shm_open() in a unsecure way.  The same risk exists if you
would use open() directly, but in that case there is mkstemp() to
prevent you from shooting yourself in the foot.  That's why OpenBSD
has shm_mkstemp().

It does look like NetBSD doesn't have shm_open() and shm_unlink() yet
though.