In the first days of January, news came out about two critical security issues called Meltdown and Spectre. They are rather serious security problems, because they affect the majority of the world’s computers.
Team Turris in cooperation with other security teams is working intensively on finding a solution to the problems.
Turris Omnia and Turris 1.x routers are potentially threatened by Spectre, which affects some processors with ARM and PowerPC architecture. As of now, there hasn‘t been any public news of how Spectre could specifically be used. However a potential attacker has to have detailed knowledge of the target processor and install dangerous code on the device beforehand in order to cause harm. This means that a potential attacker has to get the opportunity of running his own code on the victim’s device. If you use updated and safe software, the risk isn’t big on Turris Omnia devices. In light of this, we would like to warn our users not to install other software than that distributed by us on their routers. Please be extra careful, if you run virtual servers on your router using LXC containers.
Finding a reliable solution to the problems is unfortunately difficult as it requires cooperation between processor manufacturers and the Linux community. We however expect the solution to be available soon as this is a high priority issue. So far there hasn‘t been any report of Spectre attacks on Turris Omnia routers and we strongly advise our users to use recommended security settings and use only the recommended software.
https://meltdownattack.com/ is a good start for those interested in more background info (a small simple FAQ but it links to the original papers with detailed technical background are included too).
Searching the web will give you more than enough additional general (system level) info on top of that.
Wouldn’t be so sure, they speak about Power7+, question is how does it impact our weird MPC85xx which conforms to something like Power5 and anyway, they are just a local exploits so you would need to let attacker run his code on your router which is unlikely.
But don’t worry as soon as patches patches will be available we will roll them out
Yep, so no idea currently, we will see later, but that it is local exploit still holds and thus danger to the router is very limited - unless you let somebody in which would mean that you trust him quite a lot.
Hope you got your honeypots patched properly and up and running…
Might become very interesting to capture some delicious blackhat binaries from downloads (wget et al.?) or shell escape codes (echo and printf et al.?) which target those vulnerabilities.
BTW just in case is there any potentially compromising information stored or available on those machines? I hope not.
Also can they become zombies or proxies?
Just a few thoughts since I bet the full attack surface might be quite difficult to determine properly due to the complexity involved with those vulnerabilities.
Cheers and keep on rocking
I don’t think that it will be a common exploit on ssh (but I might be proven wrong). Simply because even if you manage to exploit it and download memory content you won’t found much in it unless you know what you are looking for. Common memory content is pretty mess. Picking out passwords from it is not likely although with some programs it might be done easier (for example if it has passwords stored in nice json in memory).
All exploit usage I seen so far were with exact address or with programs where memory usage was pretty strait forward. If you take in to account that to be usable with robots it has to do automatic data analysis of memory and that compiled programs pretty much end up with different memory layout every single version then I don’t think that it’s very usable exploit in dynamic world of linux (at least if you do updates).
Completely different story might be with windows (where memory layout might be same for operation system on every single pc) and for user level programs such as browsers or keyrings (where you can be sure that passwords are there or they are stored in pretty accessible format). In such case even kernel hardening or cgroups won’t help you because you can use this exploit to look into process table in kernel directly (of course if you can locate it).
What I mean by this is that on servers I think that you would have to be under targeted attack (although even that is not fine and I am not counting in cloud computing). But overall I would be more afraid about desktops where we constantly run code that no one checks without even noticing it (such as javascript in browsers).
And to our honeypots. You can try it your self. In most cases it doesn’t interpret shell at all. And it won’t run hacker’s executable. If you are real human then it’s pretty clear that you are in honeypot to you pretty fast. But if you are a robot then you will be just failing one exploit after another and giving them to us. So no, they can’t become proxy because there is no way attacker can deploy it (of course never say never, there might be some bugs).
Sorry, I can’t agree in this, because our official statement regarding Meltdown and Spectre issues, which you can also find in our website Turris deserves own thread.
It shouldn’t be as a reply to some posts, because not many people read whole topics with all replies.
Anyway I closed the other thread and @Nora included in her post that PowerPC is also affected.
With PowerPC it has never been as straightforward as it looks on Wikipedia. I think PowerPC actually came from POWER5, but it wasn’t so simple to compile something and run, even under QEMU: “PowerPC is largely based on IBM’s earlier POWER instruction set architecture, and retains a high level of compatibility with it; the architectures have remained close enough that the same programs and operating systems will run on both if some care is taken in preparation; newer chips in the POWER series use the Power ISA.” https://en.wikipedia.org/wiki/PowerPC
FYI, info about PowerPC and some implementation from Apple’s point of view: “As an operating system vendor, Apple has updated both iOS and macOS to use the dual page table mappings that are the recommended solution here. For Apple, this is perhaps not such a big change; the 32-bit x86 versions of macOS already used a similar scheme. This was because Apple wanted to give 32-bit applications access to the full 4GB of virtual memory, rather than splitting that 4GB between the program and the kernel. While this imposes a performance cost, it provided better compatibility with the PowerPC macOS, which also gave applications the full 4GB.” https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/
I apologize Pepe that my opinion is not a great point to the topic. I couldn’t help myself. Delete it when it’s too annoying.
Edit 23/1/2018: I’m patched. Whatever it means. Thanks to Apple, you thought of the rest of us, again. Even on OS X El Capitan: https://support.apple.com/en-us/HT201222.
It would be nice to see some progress on this front. I understand it is a huge challenge to provide fixes for such issues, but it seems the 4.9 and 4.15 upstream linux kernels now have fixes for Spectre v1 upstream at least:
… but that’s probably only for amd64, for ARM it’s a different story, unfortunately:
So has there been any progress here? As a OEM, Turris is in a unique position to contact your ARM manufacters and demand a fix… has this been done yet?
I would trust neither has Turris such clout since they are not likely to procure the cpu but rather the board from Compex with the cpu embedded. In which case it would be Turris -> Compex (-> board manufacturer) -> ARM manufacturer.
It would perhaps make more sense for Linux to incoporate patches in the mainline upstream kernel, which they apparently done. openWRT/LEDGE is working on the next release basis 4.9/4.14 kernel if I am not mistaken
