WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki
« previous next »
Pages: [1]   Go Down

Author Topic: TC busybox vulnerable CVE-2014-9645  (Read 4507 times)

Offline ewindisch

  • Newbie
  • *
  • Posts: 5
TC busybox vulnerable CVE-2014-9645
« on: February 09, 2015, 02:27:45 PM »
Busybox modprobe allows loading arbitrary modules. This may be triggered via syscalls that load modules automatically based on /proc/sys/kernel/modprobe.


See this:
http://www.openwall.com/lists/oss-security/2015/01/26/1
Logged

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: TC busybox vulnerable CVE-2014-9645
« Reply #1 on: February 09, 2015, 05:01:22 PM »
I would be curious where in tc ifconfig or mount gets run with user-defined content, or are there other ways to exploit this?
Logged

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: TC busybox vulnerable CVE-2014-9645
« Reply #2 on: February 09, 2015, 05:02:59 PM »
Quote from: ewindisch on February 09, 2015, 02:27:45 PM
syscalls that load modules automatically based on /proc/sys/kernel/modprobe.

Can you elaborate about those syscalls? I fail to understand. Sorry.
Logged

Offline ewindisch

  • Newbie
  • *
  • Posts: 5
Re: TC busybox vulnerable CVE-2014-9645
« Reply #3 on: February 09, 2015, 06:01:33 PM »
A PoC for userland module loading is provided here: https://lkml.org/lkml/2013/3/4/70

The above issue in CryptoAPI has been fixed, but with a vulnerable busybox modprobe will load arbitrary module modules.
Logged

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: TC busybox vulnerable CVE-2014-9645
« Reply #4 on: February 09, 2015, 06:14:48 PM »
well modprobe doesn't point to a suid busybox here, so it would still relies on cryptoAPI or other helper being "broken", right?
Logged

Offline ewindisch

  • Newbie
  • *
  • Posts: 5
Re: TC busybox vulnerable CVE-2014-9645
« Reply #5 on: February 09, 2015, 07:02:06 PM »
Yes, the kernel or a userland application must in some way facilitate this; However, the fact is that the kernel *does* facilitate this as in the CryptoAPI example. The kernel may under certain circumstances call (as root) the binary pointed to by /proc/sys/kernel/modprobe, which on TC is busybox's modprobe.
Logged

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: TC busybox vulnerable CVE-2014-9645
« Reply #6 on: February 09, 2015, 07:19:26 PM »
uuuhh, it's true, I wasn't sure if the crypto api is used or not.
trying it out with that POC is straightforward.
we are affected :(
Logged

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11049
Re: TC busybox vulnerable CVE-2014-9645
« Reply #7 on: February 10, 2015, 02:02:33 PM »
Can you test 6.1rc1, as it has updated busybox?
Logged
The only barriers that can stop you are the ones you create yourself.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: TC busybox vulnerable CVE-2014-9645
« Reply #8 on: February 10, 2015, 02:14:18 PM »
I've upgraded my boot files, have yet to reboot. But it really is trivial to test. Do rmmod ac; lsmod|grep ac; then run the compiled POC with ac as argument; lsmod|grep ac will show ac got loaded.
Logged

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11049
Re: TC busybox vulnerable CVE-2014-9645
« Reply #9 on: February 10, 2015, 02:28:07 PM »
True, but I'm not on TC at the moment.
Logged
The only barriers that can stop you are the ones you create yourself.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: TC busybox vulnerable CVE-2014-9645
« Reply #10 on: February 10, 2015, 03:30:17 PM »
yep, rc is still vulnerable with new busybox.
Logged

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11049
Re: TC busybox vulnerable CVE-2014-9645
« Reply #11 on: February 10, 2015, 04:35:37 PM »
Oh, so then there is no busybox release with the fix...
Logged
The only barriers that can stop you are the ones you create yourself.

Offline ewindisch

  • Newbie
  • *
  • Posts: 5
Re: TC busybox vulnerable CVE-2014-9645
« Reply #12 on: February 13, 2015, 04:45:47 PM »
I suppose I should note that the Crypto API had its *own* vulnerability recently fixed in the kernel. It's possible TC is vulnerable to that still.  The vuln exploited by that PoC exploit was never fixed upstream until around December 2014...
Logged
Pages: [1]   Go Up
« previous next »