dirtyc0w - explotitable on Pandora

[levi]

Many of you by now will be aware of the ditryc0w exploit, if you follow linux news at all. It's an exploit that allows an unpriveledged program to modify a file it doesn't have access to.

So, I built the exploit testing code on my Pandora and ran it. It took a while, but it did modify the file which I'd chmodded to make read only (https://raw.githubusercontent.com/dirtycow/dirtycow.github.io/master/dirtyc0w.c). Big-time erk!

So, there's unlikely to be a problem on the Pandora just yet, it's not remomotely exploitable, and nobody would have tried this technique before it was published, *and* we can mostly trust new software from users with a reputation, but it does mean that if someone we don't know now produces a new PND it might contain this exploit, and modify system software unbeknown to us.

Anyone else fancy testing this? When I tried it, it missed off the last character of my changed contents, but that may be because I used quoted parameters. It takes a little while to run - I forgot about it but it finished atfer 2 hours, and it took 20 minutes or so on my laptop (but I'd already patched that to be protected).

Do we need a patch for this? Can we expect one?

 

[PowerGod]

Does it take 2 hours with high CPU or RAM usage ? or is it mostly invisible when running ?

 

[notaz]

Well it's easy to patch the kernel with a fix, I can publish an update if that makes people to feel safer.

 

[levi]

Does it take 2 hours with high CPU or RAM usage ? or is it mostly invisible when running ?

No, I think it's mostly waiting for threads to terminate, so it wouldn't be using much CPU or RAM to do that necessarily.

Thanks for the offer of a patch notaz; much appreciated!

 

[notaz]

Ok update published. Upgraded to v3.2.83 since that includes the fix, so no need for backporting. Kind of lucky to be stuck on an LTS kernel with such a long cadence.

 

[levi]

Thanks; I have updated, rebooted and re-run the test and now the exploit fails.

FWIW, I've recently had trouble getting a network connection through my USB dongle - it'll connect to the router and I can connect to other machines on the network, but on trying to ping a known good internet address it tells me the network is unreachable. It seems a little like Windows habit of half falling off the network and going into 'local only' mode, but I've never really understood how a network device can talk to a router yet not be able to access devices through it. I'm tempted to blame the router, just I have seen this behaviour before on Windows, yet my Arch setup laptop using netctl has been rock solid (and network manager on previous older linux installs just tended to fall off the network entirely periodically).

Edit: Also, I've now timed the test more accurately, and it completes in under 10 minutes on my Pandora 1GHz.

 

[levi]

FWIW, there's been new news on this exploit, which has turned into a new exploit called 'huge dirty cow'. It's still not remotely exploitable, and this time depends on us having enabled support for transparent huge memory mapped pages.

The documentation suggests there should be files in /sys/kernel/mm/transparent_hugepage which define whether THP is active and for what purposes. My Arch boxes have it configured for 'always' but my pandora only has it configured for threads that have been marked 'madvise', and looking inside some of the stats pages inside the khugepage in there, it seems on my Pandora which has been up for a few weeks running an mp3 player and occasionally pndmanager has not collapsed any non-huge pages yet. There's nothing stopping an exploit marking itself madvise which might expose the use case for this particular hole mind you.

I doubt whether it's worth fixing anyway however; we can configure our own pandoras not to use THPs if we care, and with only magicsam, ptitseb and canseco regularly still producing new software I think we can trust them not to hack our Pandoras anyway. With support for the 3.2 kernel running out in May next year, we're probably better off using our time to improve the Letux OS which looks to be the OS to use if we want to keep our Pandora's up to date. So long, SuperZaxxon - it's been fun!

Further reading:

https://medium.com/bindecy/huge-dirty-cow-cve-2017-1000405-110eca132de0

https://lwn.net/Articles/423592/

 

[notaz]

There's nothing stopping an exploit marking itself madvise which might expose the use case for this particular hole mind you.

Yes but that won't give it anything. The whole point of DirtyCOW is to overwrite memory of a different privileged process, and because no privileged process is using huge pages on pandora ('madvise' configuration instead of 'always', when nobody I'm aware of calls madvice(HUGE...)), there is no way to do that. Yes the exploit can overwrite it's own read only pages this way, but there is no benefit from that. Thus this is not exploitable on pandora.