linux-kernel - Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1383751951.28218.64.camel@flatline.rdu.redhat.com>
Date:	Wed, 06 Nov 2013 10:32:31 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Kees Cook <keescook@...omium.org>, Will Drewry <wad@...omium.org>,
	Richard Weinberger <richard@....at>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	libseccomp-discuss@...ts.sourceforge.net,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt
 OABI syscalls

On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> [cc: some ARM people]
> 
> After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
> driver and qemu 1.6 don't get along.  It would be great if some
> kernel.org page described a standard way to boot a modern Linux image
> on a modern QEMU version, but I digress.)
> 
> The current state of affairs is unhealthy.  I wrote a program
> (attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
> getgid syscall in OABI").  The registers I program are:
> 
> r0: 1
> r1: 2
> r2: 3
> r3: 4
> r4: 5
> r5: 6
> 
> (i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)
> 
> r7: 1
> 
> (r7 is the EABI syscall register.  On a kernel without OABI support,
> the immediate svc argument is ignored and syscall 1, i.e. _exit, will
> be invoked).
> 
> Seccomp sees the registers as I set them (unsurprisingly) and it sees
> nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
> exists.  This is, IMO, bad.  The OABI and EABI argument passing
> conventions are *not* the same, and seccomp filters that check syscall
> argument values may be spoofable by using OABI calls.
> 
> I suspect that audit, perf, ftrace, and maybe even ptrace are broken
> as well for exactly the same reason.
> 
> I would argue that there are two reasonable fixes:
> 
> 1. Set a different audit arch for OABI syscalls (e.g.
> AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> that x86_64 treats int 80.

As the audit maintainer, I like #1.  It might break ABI, but the ABI is
flat wrong now and not maintainable...

> 
> 2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
> syscalls would look like a different set of syscalls on the same
> architecture.  That is, treat OABI syscall entries kind of like x86_64
> treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
> N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)
> 
> 3. Unconditionally kill any process that makes an OABI syscall with
> seccomp enabled (because there should be no such programs).  Eww.
> 
> Options 1 and 2 are both break ABI, but I doubt that anythink cares.
> OABI is, AFAICT, mostly dead.  That being said, even if nothing
> legitimate uses OABI, exploits against seccomp-using programs can
> certainly use OABI, so I think that this needs to be fixed somehow.
> 
> Thoughts?  I think I prefer option 1.  I don't really want to make the
> change because my ARM assembly skills are lacking.
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> libseccomp-discuss mailing list
> libseccomp-discuss@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/