Critical security issues Meltdown and Spectre

Dear Turris users,

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.

Stay safe!

Team Turris


Thanks for your prompt response! 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.

Hello Nora,

looks like even Turris 1.x is in danger according to this press release from IBM:


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 :wink:


Ehmm no,

“security vulnerability impacting all microprocessors, including processors in the IBM POWER family.”

and they speak about power7+ in this:

“Firmware patches for POWER7+, POWER8 and POWER9 platforms will be available on January 9.”

and about everything else in this:

“We will provide further communication on supported generations prior to POWER7+, including firmware patches and availability.

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.

And part about releasing patches also holds :wink:

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 :slight_smile:

AFAIK the Turris honeypots act just as a proxy, and the connection is processed elsewhere to reduce the risk of exploitation.

1 Like

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).

Spectre & Meltdown Checker:

my output (kernel 4.4.106-1e4a549d177ab3da12b2052fba6a4dd5-3)

Spectre and Meltdown mitigation detection tool v0.09

CVE-2017-5753 [bounds check bypass] aka ‘Spectre Variant 1’

  • Kernel compiled with LFENCE opcode inserted at the proper places: UNKNOWN (couldn’t find your kernel image in /boot)


CVE-2017-5715 [branch target injection] aka ‘Spectre Variant 2’

  • Mitigation 1
  • Hardware (CPU microcode) support for mitigation: UNKNOWN (couldn’t read /dev/cpu/0/msr, is msr support enabled in your kernel?)
  • Kernel support for IBRS: NO
  • IBRS enabled for Kernel space: NO
  • IBRS enabled for User space: NO
  • Mitigation 2
  • Kernel compiled with retpolines: ./ line 187: zgrep: not found

STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpolines are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka ‘Meltdown’ aka ‘Variant 3’

  • Kernel supports Page Table Isolation (PTI): ./ line 235: zgrep: not found
  • PTI enabled and active: NO

STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

That script is oversimplifying and x86 specific.



IBM announcement:

please don’t make duplicate posts.
We know that PowerPC is affected, too.

This thread has 13 posts and users told the same as you in post #3,#5.

I’d like to keep forum organized.
We didn’t update OP, we’re working on but, in the meantime you can read updated article on our website:

Thank you for your understanding.


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.

//EDIT @Perry it’s OK. This belongs here. :slight_smile:


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.”

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.”

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: Apple made some progress here: Some of us can sleep a bite better.

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:

1 Like

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:

According to this, the 4.4 kernel in Omnia also had a backport for the fix:

… 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?


1 Like

To me personally, a few thousand chips doesn’t seem a strong position at all, compared to e.g. phone vendors. (I’m sorry to be so negative.)

That’s still better than a random wazzoo like me who has no commercial relationship with an actual ARM vendor at all. :slight_smile:

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