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