Date: Mon, 25 Jan 2016 12:51:55 +0100 From: Jann Horn <jannhorn@...glemail.com> To: Daniel Sangorrin <daniel.sangorrin@...hiba.co.jp> Cc: linux-kernel@...r.kernel.org, wad@...omium.org, kernel-hardening@...ts.openwall.com, keescook@...omium.org, Andy Lutomirski <luto@...capital.net>, Alexei Starovoitov <alexei.starovoitov@...il.com>, Paul Moore <paul@...l-moore.com>, linux-api@...r.kernel.org Subject: RE: [RFC PATCH 1/1] seccomp: provide information about the previous syscall Am 25.01.2016 4:40 vorm. schrieb "Daniel Sangorrin" < daniel.sangorrin@...hiba.co.jp>: > There were a few important points that I didn't mention but are critical to understand > what I was trying to do. The focus of the patch was on protecting "real-time > embedded IoT devices" such as a PLC (programmable logic controller) inside a factory > assembly line . > > They have a few important properties that I took into consideration: [...] > - Mimicry: as I mentioned in the cover letter (and Jann showed with > his ROP attack) if the attacker is able to emulate the system call's order > (plus its arguments and the address from which the call was made) > this patch can be bypassed. However, note that this is not easy for several > reasons: > + the attacker may need a long stack to mimic all the system calls and their > arguments. Note that in a ROP attack, the attacker will often set up his own stack anyway, so I'm not sure how much of a constraint a short stack really is. > + the stealthy attacker must make sure the real-time application does not > crash, miss any of its deadlines or cause deadline misses in other apps > [Note] Real-time application binaries are usually closed source so > this might require quite a bit of effort. > + randomized system calls: applications could randomly activate dummy > system calls each time they are instantiated (and adjust their BPF filter, > which should later be zeroed). In this case, the attacker (or virus) > would need to figure out which dummy system calls have to > be mimicked and prepare a stack accordingly. This seems challenging. > [Note] under a brute force attack, the application may just raise an alarm, > activate a redundant node (not connected to the network) and > commit digital suicide :). > > About the ABI, by all means I don't want to break it. If putting the field at > the end does not break it, as Alexei mentioned, I can change it. Also I would > be glad to review the SECCOMP_FILTER_FLAG_TSYNC flag mentioned by Jann > in case there is any interest. > > However, I'll understand the NACK if you think that the maintenance is not worth it > as Andy mentioned; that it can be bypassed under certain conditions; or the fact > that it focuses on a particular type of systems. I will keep reading the > messages in the kernel-hardening list and see if I find another topic to > contribute :). You might want to look into CFI (control flow integrity) - that's probably a much stronger mitigation than this, and it does not require kernel support. It also works by verifying transitions, but it checks transitions of userspace code instead of syscall transitions. Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.