uname26 exploit regression test
cover uname26 exploit regression test
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
Signature · 1 line
2.11.0
cover uname26 exploit regression test
Hi!
Quoted 9 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
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.
Quoted 4 lines
4) This is maybe a question for a
security/kernelmailing 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.
Signature · 2 lines
Cyril Hrubis [email protected]
cover uname26 exploit regression test
Quoted 6 lines · On Mon, 20 Feb 2017 11:11:16 +0100 "Cyril Hrubis" <[email protected]> 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/exploitsorsecurity/CVEdirectory 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 :-))).
Quoted 7 lines
Quoted 3 lines
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.
cover uname26 exploit regression test
Hi!
Quoted 10 lines
Quoted 6 lines
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/exploitsorsecurity/CVEdirectory or something.Perhaps use
security/CVEdirectory 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.
Quoted 4 lines
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...
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 5 lines
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...
Signature · 2 lines
Cyril Hrubis [email protected]