Language Selection

English French German Italian Portuguese Spanish

Security: Updates, SS7, Docker, Thunderbolt, Django

Filed under
Security
  • Security updates for Monday
  • SS7 Cellular Network Flaw Nobody Wants To Fix Now Being Exploited To Drain Bank Accounts

    Back in 2017, you might recall how hackers and security researchers highlighted long-standing vulnerabilities in Signaling System 7 (SS7, or Common Channel Signalling System 7 in the US), a series of protocols first built in 1975 to help connect phone carriers around the world. While the problem isn't new, a 2016 60 minutes report brought wider attention to the fact that the flaw can allow a hacker to track user location, dodge encryption, and even record private conversations. All while the intrusion looks like ordinary carrier to carrier chatter among a sea of other, "privileged peering relationships."

    Telecom lobbyists have routinely tried to downplay the flaw after carriers have failed to do enough to stop hackers from exploiting it. In Canada for example, the CBC recently noted how Bell and Rogers weren't even willing to talk about the flaw after the news outlet published an investigation showing how, using only the number of his mobile phone, it was possible to intercept the calls and movements of Quebec NDP MP Matthew Dubé.

    But while major telecom carriers try to downplay the scale of the problem, news reports keep indicating how the flaw is abused far more widely than previously believed. This Motherboard investigation by Joseph Cox, for example, showed how, while the attacks were originally only surmised to be within the reach of intelligence operators (perhaps part of the reason intelligence-tied telcos have been so slow to address the issue), hackers have increasingly been using the flaw to siphon money out of targets' bank accounts, thus far predominately in Europe...

  • Doomsday Docker Security Hole Uncovered

    Red Hat technical product manager for containers, Scott McCarty, warned: "The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it. While there are very few incidents that could qualify as a doomsday scenario for enterprise IT, a cascading set of exploits affecting a wide range of interconnected production systems qualifies...and that's exactly what this vulnerability represents."

  • Doomsday Docker security hole uncovered
  • It starts with Linux: How Red Hat is helping to counter Linux container security flaws

    The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it. A cascading set of exploits affecting a wide range of interconnected production systems qualifies as a difficult scenario for any IT organization and that’s exactly what this vulnerability represents.

    For many Red Hat end users, it’s unlikely that this flaw gets that far. IT organizations using Red Hat Enterprise Linux to underpin their Linux container and cloud-native deployments are likely protected, thanks to SELinux. This vulnerability is mitigated by the use of SELinux in targeted enforcing mode, which prevents this vulnerability from being exploited. The default for SELinux on Red Hat Enterprise Linux 7 is targeted enforcing mode and it is rarely disabled in a containerized environment.

  • Kubernetes, Docker, ContainerD Impacted by RunC Container Runtime Bug

    The Linux community is dealing with another security flaw, with the latest bug impacting the runC container runtime that underpins Docker, cri-o, containerd, and Kubernetes.

    The bug, dubbed CVE-2019-5736, allows an infected container to overwrite the host runC binary and gain root-level code access on the host. This would basically allow the infected container to gain control of the overarching host container and allow an attacker to execute any command.

  • Thunderbolt preboot access control list support in bolt

    Recent BIOS versions enabled support for storing a limited list of UUIDs directly in the thunderbolt controller. This is called the pre-boot access control list (or preboot ACL), in bolt simply called "bootacl". The devices corresponding to the devices in the bootacl will be authorized during pre-boot (and only then) by the firmware. One big caveat about this feature should be become obvious now: No device verification can happen because only the UUIDs are stored but not the key, so if you are using SECURE mode but enable preboot ACL in the BIOS you effectively will get USER mode during boot.

    The kernel exposes the bootacl via a per-domain sysfs attribute boot_acl. Every time a device is enrolled, boltd will automatically add it to the bootacl as well. Conversely if the device is forgotten and it is in the bootacl, boltd will automatically remove it from the bootacl. There are is small complication to these seemingly straight forward operations: in BIOS assist mode, the thunderbolt controller is powered down by the firmware if no device is connected to it. Therefore when devices are forgotten boltd might not be able to directly write to the boot_acl sysfs attribute. In a dual boot scenario this is complicated by the fact that another operating system might also modify the bootacl and thus we might be out of sync. As the solution to this boltd will write individual changes to a journal file if the thunderbolt controller is powered down and re-apply these changes (as good as possible) the next time the controller is powered up.

  • Django security releases issued: 2.1.6, 2.0.11 and 1.11.19

Django bugfix releases: 2.1.7, 2.0.12 and 1.11.20

IDG on Docker/CVE-2019-5736

Patch this run(DM)c Docker flaw or you be illin'...

And the obligatory daily FUD

Bogdan Popa at It Again...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Mozilla on Nuisance Videos and Servo Progress

Programming and HowTos: The Leftovers

Gustavo Silva: Disco Dingo Thoughts

Those already around me know I love Linux and my favourite linux distribuition is Ubuntu. One of the reasons Ubuntu is my favourite is how simple and compatible it is with pretty much all devices I have tried installing. Except my laptop, but that’s due to the graphics card. But hey, I fondly received the news that now we can select the option to automatically set nomodeset and other convenient tools when running the setup. For me, this means a major win. I previously had to set nomodeset manually and after installation I had to immediately modifiy some options in the grub’s defaults (namely set the acpi=force) but now, with this new option, the installation process which was already smooth, become (melted) butter. Thank you, honestly, person who remembered to include this option. This seems like a feature that will stick to Ubuntu 20.04, so I’m happy to now a LTS version will become even simpler to install too, so that’s great. The UI and custom-Gnome experience has been improved as well, in this custom flavour of Gnome. We now have a few more options for customization, including dark options of the themes but I am definitely pleased to say that the Gnome shell, in Ubuntu 19.04, really looks great. Read more

5 of the Best Linux Desktops for Touchscreen Monitors in 2019

The concept of using Linux on a touchscreen monitor or two-in-one computer has come a long way. Touchscreen support is now built into the Linux kernel, so theoretically any Linux distribution should run with a touchscreen. That said, not every distribution will be easy to use on a touchscreen, and this comes down to the desktop. For example, using a tiling window manager like Awesome or i3 isn’t going to do you much good on a touchscreen. Choose the right desktop (more precisely, desktop environment), and you’ll have a much better time using Linux with a touchscreen. Read more