[CVE-2014-3153][root] Linux kernels < 3.14.5

Search This thread

ZaraByte

Member
Dec 29, 2010
28
2
Fort Myers
www.zarabyte.com
I couldn't find the source to any, but it would be simple to check your kernel version and update it!

Sent from my RAZR M xt907 (KitStalk) using Tapatalk

Joel Eriksson is the person who made the exploit however i don't think he wants to make it public just yet.
As far as i know their is not a an official kernel patch released but Ubuntu yet to fix it im not even sure if my 3.13.0-27-generic is effected by it or not.

The good thing is they need to run the exploit locally on the machine so they first have to get access to your site via an security hole.
Not too worried about my phone or tablet getting hacked least of my worries but when your running a website thats more of a problem.
Their is a patch out for websites but its not from the official site im not taking no risk installing something :D
 
  • Like
Reactions: xKroniK13x

Top Liked Posts

  • There are no posts matching your filters.
  • 6
    CVE-2014-3153 was published 5 June 2014.

    Affected Kernels: <= 3.14.5 (see specifics)
    Affected Devices: Multiple!


    As of last night, security researcher @geohot proved that the Samsung Galaxy S5 from AT&T
    was vulnerable, by gaining root. He also believes the Verizon version is affected.

    The details of this can be found here:
    http://seclists.org/oss-sec/2014/q2/467
    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3153
    http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3153
    http://www.reddit.com/r/netsec/comments/27fl04/another_linux_kernel_exploit_this_time_reachable/


    The description of the vulnerability is best described by the comments from the experts themselves:

    From seclists.org:

    Pinkie Pie discovered an issue in the futex subsystem that allows a local user to gain ring 0 control via the futex syscall. An unprivileged user could use this flaw to crash the kernel (resulting in denial of service) or for privilege escalation.
    Specifically, the futex syscall can leave a queued kernel waiter hanging on the stack. By manipulating the stack with further syscalls, the waiter structure can be altered. When later woken up, the altered waiter can result in arbitrary code execution in ring 0. This flaw is especially urgent to fix because futex tends to be available within most Linux sandboxes (because it is used as a glibc pthread primitive).
    This is a serious flaw from all levels, as one commenter state:

    Indeed. This is probably the biggest security flaw in Linux in the past 5 years (if not the biggest ever) since it allows a full kernel compromise even from extremely tight sandboxes...
    Or as user gsuberland writes and explains in this Reddit thread:
    Ok, so I read the code, and I think I know what's happening. A futex is a "fast usermode mutex", which is kind of locking mechanism for memory pages that prevents bad things like two threads writing to a page at the same time.
    There's a function in the implementation called futex_requeue(), which "requeues waiters from uaddr1 to uaddr2". I'm not really sure what that means, but basically uaddr1 is the address of a source futex in user-mode memory, and uaddr2 is the address of a destination futex in user-mode memory. But, because it was assumed that they'd always be distinct, the code provisions a bunch of stuff expecting to have two objects to deal with, and in the end some of them are just left there doing nothing - they point to uninitialised structures or memory.
    Basically, the trick is that if you get a futex and call futex_requeue() with your futex as both uaddr1 and uaddr2, the structure that describes the futex (in user-mode memory, which you can access) is left with "dangling pointers", i.e. pointers to memory that hasn't been allocated yet. By then looking at those pointers and allocating memory to the locations it describes, you can write your own stuff there. Once execution passes down to kernel-mode, you've essentially got a situation where kernel-mode code is using data that you control, but in a context where it expects the data to be trusted. This could lead to all sorts of nasty stuff like read-what-where or write-what-where conditions, which can be used to privesc.
    I probably got some of this wrong so don't quote me, but hopefully I at least described the core of the issue correctly.
    EDIT: Also, I don't know why this is linked to as an "exploit". The Chrome bit makes sense once you read OP's comment about the sandbox escape - basically Chrome didn't restrict certain futex-related calls which could be used to trigger this bug. I still don't know how exploitable it is, though, or which vector would be used to exploit it. As far as I can tell it's just a "this is probably bad" situation until someone finds kernel-mode futex code that can be messed with by crafting data to coincide with the dangling pointers. Feel free to correct me if I'm wrong, though.
    2
    Since geohot said he wouldn't be releasing the exploit publicly, can we talk a bit of methodology/implementation. I for one would really like to get this moving forward for those having att & vzw. Basically, what do we need to do to trigger the futex_requeue error utilising chrome?

    Did I read right that it said you need a ChromeOS to be able to trigger it?

    You do not need to execute this through Chrome. It is a generic flaw in the Linux kernel, that happens to be shared on many, many Android devices. I have been studying this for the Razr M (vulnerable), and have been coming up with theories how to implement this...

    Basically, the futex_requeue error allows a segment of code to be written to memory, and then executed as root. This means that you can modify system files through this error, meaning that you can write scripting that will gain root, save it to the memory, and execute it.

    I am trying to implement this on my Razr M, and have even more incentive seeing that it was used of the Galaxy successfully. I don't have a lot of experience in this area, but am researching a lot and have a couple of theories to try out.

    I should note that this is just my understanding on the exploit, and I am only in the very early stages researching it... I could be completely wrong.
    2
    "..There's a function in the implementation called futex_requeue(), which "requeues waiters from uaddr1 to uaddr2". I'm not really sure what that means, but basically uaddr1 is the address of a source futex in user-mode memory, and uaddr2 is the address of a destination futex in user-mode memory. But, because it was assumed that they'd always be distinct, the code provisions a bunch of stuff expecting to have two objects to deal with, and in the end some of them are just left there doing nothing - they point to uninitialised structures or memory.
    Basically, the trick is that if you get a futex and call futex_requeue() with your futex as both uaddr1 and uaddr2, the structure that describes the futex (in user-mode memory, which you can access) is left with "dangling pointers", i.e. pointers to memory that hasn't been allocated yet. By then looking at those pointers and allocating memory to the locations it describes, you can write your own stuff there. Once execution passes down to kernel-mode, you've essentially got a situation where kernel-mode code is using data that you control, but in a context where it expects the data to be trusted..."



    aah, terminal - "man futex" .. the man pages -

    http://man7.org/linux/man-pages/man2/futex.2.html

    how it ties in with the mobile phones, it has to do with the network sockets within the android (linux) kernel..

    even the nexus 5 is reported to be issued an security update in relaton to this - https://community.sprint.com/baw/thread/163896 & that's only labeled a *security patch*...


    these socket views came up some years ago, in the gnome d.e. & was asked about, & they're all related to network timing sockets -

    What is the “Waiting Channel” of a process?

    ~good link~

    you could actually see them, then analyze them later with the netstat command, & see the process in action via **cat /proc/some_pid/stack** in a shell..


    in the upper userspace, you can *feel* it on action on your phone;

    especially on a nexus 5 on sprint -

    it's single path at a time triband rf chip when it lulls to/from lte to 3g at times, some ppl complain they see a *telephone calls unavailable now* or something to that nature,

    or wifi that won't catch when turned on

    or an lte signal that simply won't latch, keeping them stuck on 3g..


    underneath in that chipset, it's like a human mind processing a blank for a few trying to decide before acting,

    ** it's that dead moment**

    right then, that this issue speaks of, like below from that gnome link in '10..


    1.A task can be either a Process3 or a Thread2
    2.A Thread is a sub-section of a Process. Many threads can run parallel
    3.A process is a full-blown program, it consists of one or more threads, though a program can consist of multiple processes as well.
    4.Remember, this is still a very high level view of things, it's not considering the implementation details


    __skb_recv_datagram

    Wait for some data on a locked network socket.


    sk_wait_data

    Wait for some data on a network socket.


    do_exit

    This is the last part of quitting a process. do_exit() calls the schedule() next, to schedule another process. When do_exit() is called, the process is a ZOMBIE.


    do_wait

    A process is added to the schedulers wait queue.


    pipe_wait, unix_stream_data_wait

    A Process is waiting for data from a subprocess. This happens, for example, when you run this sort of code:




    ooh, the *top* command can expose the upper levels of those processes also!

    you know when i can *see* it?

    when i'm listening to music while riding the subway underground with my nexus 5;

    as my signal changes between stops losing service, re-gaining it.. it effects the volume of the music, this morning, the train had to pause between stops in a tunnel, & my music player sounded kind of muffled but the music was, edible for my ears, that pause in the tunel, made the nexus 5 lose total signal, & BAM, that loss, of processing in the networking , gave me gain in volume with the music player!


    it's related to one chip doing all the work...
    1
    Yes, I am willing to test it, however, I believe it is confirmed not working for the 2012 Droid series (HD, MAXX, M).

    Sent from my XT907 using Tapatalk

    Let me know, it was working a few months ago but may have been patched

    Sent from my MotoX+1 using XDA Premium 4 mobile app
    1
    it's not that towelroot, was **malicious by intent** ;

    i don't believe so, it was coded with good intentions, it's just had, a nasty side effect; in a nutshell -

    ". . .the app runs some code, the code crashed [sic] android and leave it confused, in its confused state it thinks that the app should be root, then the app installs something to allow other apps to become root..."

    ‘Towelroot’ exploit reveals security nightmare for Android

    me.. i like to understand HOW things work, see & study the source of why it fails, or why it does things better than whatever, before simply adding it in, w/o any understanding at all of how it work.. that's just me...


    like if i'm to modify the radio on the nexus 5, do i understand HOW it works better than the older or newer radio? .. many would ask "should i"?

    just take it on word from others that it just works, or an issue is what it is, ther's no way around it...

    sorry, i'm not built like that..