[LTP] [PATCH 0/1] uname26 exploit regression test

[LTP] [PATCH 0/1] uname26 exploit regression test

[Richard Palethorpe]

Hi,

I have essentially rewritten the following expoit to be used in the LTP:
https://www.exploit-db.com/exploits/37937/ (Metan's idea AFAIK). There are
some issues which I came across while doing this, even though it is quite an
easy exploit to recreate.

1) How should we organise the exploit tests? I see Metan has added dirtyc0w
   under that name in its own folder. Not all exploits have a fancy or unique
   name however. I have just named the uname exploit with its CVE name and put
   it in a new uname folder, but I'm not sure that is the best way either.

2) What is the appropriate runtest file for security tests? I think they
   should be separated from functional tests.

3) The exploit code from the link is licensed under GPLv3. Although I rewrote
   the LTP test from scratch, the fact I saw the exploit code raises the
   question of whether my test is a derivative work. The easiest thing to do
   would be to attribute the exploit code author and simply state that the
   test is an adaptation, but then I believe the test would need to be GPLv3.
   Of course, I can just ask the author to relicense the original under GPLv2,
   but lets assume they don't consent or can't be contacted.

4) This is maybe a question for a security/kernel mailing list, but which
   exploits are most likely to be reintroduced to the kernel? I am not sure
   that this exploit is at high risk of being reintroduced. At least not into
   mainline or any of the major distro branches.

Thank you,
Richard.

Richard Palethorpe (1):
  security: Test for uname26 exploit cve-2012-0957

 testcases/kernel/security/uname/.gitignore      |  1 +
 testcases/kernel/security/uname/Makefile        | 20 ++++++
 testcases/kernel/security/uname/cve-2012-0957.c | 86 +++++++++++++++++++++++++
 3 files changed, 107 insertions(+)
 create mode 100644 testcases/kernel/security/uname/.gitignore
 create mode 100644 testcases/kernel/security/uname/Makefile
 create mode 100644 testcases/kernel/security/uname/cve-2012-0957.c

-- 
2.11.0

[LTP] [PATCH 0/1] uname26 exploit regression test

[Cyril Hrubis]

Hi!
> I have essentially rewritten the following expoit to be used in the LTP:
> https://www.exploit-db.com/exploits/37937/ (Metan's idea AFAIK). There are
> some issues which I came across while doing this, even though it is quite an
> easy exploit to recreate.
> 
> 1) How should we organise the exploit tests? I see Metan has added dirtyc0w
>    under that name in its own folder. Not all exploits have a fancy or unique
>    name however. I have just named the uname exploit with its CVE name and put
>    it in a new uname folder, but I'm not sure that is the best way either.

Sounds reasonable. I guess that for some exploits there is no single
syscall to blame so putting these into syscalls/ does not make much
sense.

Maybe we can just put all these tests into an security/exploits or
security/CVE directory or something.

> 2) What is the appropriate runtest file for security tests? I think they
>    should be separated from functional tests.

If there is none we should start one. Something as runtest/security. I'm
also wondering if we should add these into the runtest/syscalls as well,
at least these that are directly related to a syscall of some kind.

> 3) The exploit code from the link is licensed under GPLv3. Although I rewrote
>    the LTP test from scratch, the fact I saw the exploit code raises the
>    question of whether my test is a derivative work. The easiest thing to do
>    would be to attribute the exploit code author and simply state that the
>    test is an adaptation, but then I believe the test would need to be GPLv3.
>    Of course, I can just ask the author to relicense the original under GPLv2,
>    but lets assume they don't consent or can't be contacted.

I will double check if there are any problems with having GPLv3 test but
I do not see any. As far as the LTP library is 'GPLv2 or any later' we
can link GPLv3 test against it. And since we basically distribute source
code only GPLv3 test should not do any harm.

It would be better to have the test code under GPLv2+ but if original
author cannot be reached this should not stop us.

> 4) This is maybe a question for a security/kernel mailing list, but which
>    exploits are most likely to be reintroduced to the kernel? I am not sure
>    that this exploit is at high risk of being reintroduced. At least not into
>    mainline or any of the major distro branches.

I guess that anything that expects precise memory layout and works only
on a single distro is out of a question. Generally I would expect race
conditions to be much more easily reintroduced than anything else, since
locking in kernel is tricky. But yes, this is question to be discussed
with kernel developers as well.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH 0/1] uname26 exploit regression test

[Richard Palethorpe]

On Mon, 20 Feb 2017 11:11:16 +0100
"Cyril Hrubis" <chrubis@suse.cz> wrote:

> Sounds reasonable. I guess that for some exploits there is no single
> syscall to blame so putting these into syscalls/ does not make much
> sense.
> 
> Maybe we can just put all these tests into an security/exploits or
> security/CVE directory or something.

Perhaps use security/CVE directory then list the exploits by CVE number is
best. Then if someone needs to find an exploit for a particular syscall they
will need to grep its name or they could look it up in a CVE database.

Maybe you could add a field in the test struct for keywords and then at some
later date we could add an option to the test runner to search for tests with
some particular keywords or other meta data? (I am thinking about the -q
option you added for runltp-ng (good work btw :-))).

> 
> > 2) What is the appropriate runtest file for security tests? I think they
> >    should be separated from functional tests.  
> 
> If there is none we should start one. Something as runtest/security. I'm
> also wondering if we should add these into the runtest/syscalls as well,
> at least these that are directly related to a syscall of some kind.

This does mean we will end up unintentionally running some tests twice,
although maybe runltp stops that. In fact if all the tests are named cve-*
then it is easy to stop that.

In any case some exploits are likely to run a long time or crash the system if
successful so I would either want to keep them seperate or have some way of
labeling them as dangerous or long running. For example I started running the
OOM killer tests separately in OpenQA from the other memory tests because they
are very good at causing freezes and stop the other tests from running.

Thank you,
Richard.

[LTP] [PATCH 0/1] uname26 exploit regression test

[Cyril Hrubis]

Hi!
> > Sounds reasonable. I guess that for some exploits there is no single
> > syscall to blame so putting these into syscalls/ does not make much
> > sense.
> > 
> > Maybe we can just put all these tests into an security/exploits or
> > security/CVE directory or something.
> 
> Perhaps use security/CVE directory then list the exploits by CVE number is
> best. Then if someone needs to find an exploit for a particular syscall they
> will need to grep its name or they could look it up in a CVE database.

Agreed.

> Maybe you could add a field in the test struct for keywords and then at some
> later date we could add an option to the test runner to search for tests with
> some particular keywords or other meta data? (I am thinking about the -q
> option you added for runltp-ng (good work btw :-))).

I have something like that in mind, adding metadata to reference kernel
commits for regression tests, tagging System V IPC tests with 'sysv_ipc'
tag, etc. Could be done as simply as adding an array of strings (tags)
to the test structure, then we just can just print them with "tag:"
prefix for the -q option, however tagging ~1000 testcases will be quite
time consuming...

> > > 2) What is the appropriate runtest file for security tests? I think they
> > >    should be separated from functional tests.  
> > 
> > If there is none we should start one. Something as runtest/security. I'm
> > also wondering if we should add these into the runtest/syscalls as well,
> > at least these that are directly related to a syscall of some kind.
> 
> This does mean we will end up unintentionally running some tests twice,
> although maybe runltp stops that. In fact if all the tests are named cve-*
> then it is easy to stop that.

We have overlap in the runtest files at the moment, there are a few that
are a subset of the syscalls runtest file. Tagging all the tests would
fix that problem, since then we could filter tests by tags, but even if
we decide to go this way, that will took us at least year to implement.

> In any case some exploits are likely to run a long time or crash the system if
> successful so I would either want to keep them seperate or have some way of
> labeling them as dangerous or long running. For example I started running the
> OOM killer tests separately in OpenQA from the other memory tests because they
> are very good at causing freezes and stop the other tests from running.

There are at least three syscall tests that can bring the machine down
as well, mostly regresion tests for races in fs...

-- 
Cyril Hrubis
chrubis@suse.cz