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

Matthieu Herrb matthieu.herrb at laas.fr
Thu Nov 14 22:58:27 PST 2013


On Thu, Nov 14, 2013 at 06:18:06PM -0800, Alan Coopersmith wrote:
> As we expand our use of shared memory via the new extensions, we should try
> to make sure we're not making more problems along the lines of those mentioned
> in the presentation linked below & associated whitepaper published at:
>
http://labs.portcullis.co.uk/whitepapers/memory-squatting-attacks-on-system-v-shared-memory/ 
> 
> (It does seem most of the issues are in the clients creating shmem insecurely
>  before passing it to the X libraries, but I've not had time to do much analysis
>  beyond a quick readthrough of the slides & paper.)

In the case of the old MIT-SHM extension it has always been
problematic when the client and X server don't run under the same
uid. X can abuse its root privileges (if any) to access any SHM
segement, but this doesn't work if you run the server under an
un-privileged uid.  You can play tricks to try to get both into the
same group to grant access tho the SHM to both of them, but it's not
easy and doesn't scale.

My understanding is that the new code, by passing shared memory
through fd is a lot better since it doesn't rely on file system
permissions to control access, but rathers uses the file descriptor as
the access key, so only processes which share the file descriptor
through fd passing can access it.

At some point we should deprecate the old MIT-SHM API though.

> 
> 	-alan-
> 
> 
> -------- Original Message --------
> Subject: [oss-security] "I miss LSD", slides, paper and tools relating to
> finding UNIX system level vulnerabilities (as given at 44CON)
> Date: Thu, 14 Nov 2013 12:20:23 +0000
> From: Tim Brown <tmb at 65535.com>
> Reply-To: oss-security at lists.openwall.com
> To: oss-security at lists.openwall.com
> 
> All,
> 
> Some of you may already have spotted this, but last night we published our
> slides, paper and some tools from my talk at 44CON earlier in the year.  The
> content can be found at:
> 
> * http://labs.portcullis.co.uk/presentations/i-miss-lsd/
> 
> The take home points around the System V shared memory issues (detailed in
> more detail in the linked to paper) are:
> 
> * System V shared memory is often created with weak permissions.
> * Usage of System V shared memory by X11 applications is particularly
> problematic.
> * Qt Project patched Qt APIs (CVE-2013-0254), Oracle patched Java JRE
> (CVE-2013-1500), Google patched Chrome independently.
> * No progress has been made on the problem more generally by either Red Hat or
> Debian.
> * Coccinelle is an effective tool for performing static analysis on large
> corpuses of C.
> * Memory corruption attacks against System V shared memory are unlikely.
> 
> I've also released a tool called smaSHeM (again linked to) for dumping System
> V shared memory and for manipulating it.
> 
> Tim
> -- 
> Tim Brown
> <mailto:tmb at 65535.com>
> 
> 
> 


> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel


-- 
Matthieu Herrb


More information about the xorg-devel mailing list