This Week In Security: Camera Feeds, Python 2, FPGAs

Networked cameras keep making the news, and not in the best of ways. First it was compromised Ring accounts used for creepy pranks, and now it’s Xiaomi’s stale cache sending camera images to strangers! It’s not hard to imagine how such a flaw could happen: Xiaomi does some video feed transcoding in order to integrate with Google’s Hub service. When a transcoding slot is re-purposed from one camera to another, the old data stays in the buffer until it is replaced by the new camera’s feed. The root cause is probably the same as the random images shown when starting some 3D games.

Python is Dead, Long Live Python

Python 2 has finally reached End of Life. While there are many repercussions to this change, the security considerations are important too. The Python 2 environment will no longer receive updates, even if a severe security vulnerability is found. How often is a security vulnerability found in a language? Perhaps not very often, but the impact can be far-reaching. Let’s take, for instance, this 2016 bug in zipimport. It failed to sanitize the header of a ZIP file being processed, causing all the problems one would expect.

It is quite possible that because of the continued popularity and usage of Python2, a third party will step in and take over maintenance of the language, essentially forking Python. Unless such an event happens, it’s definitely time to migrate away from Python2.

FPGAs Accelerating Memory Attacks

Certain commercial sectors are constantly pushing for more performance, and as a result, Intel has begun shipping servers that have FPGA co-processors. These FPGAs have direct access to system memory, and can operate at very high data rates. Could it be that this integration has led to unforeseen security problems?

A group of researchers have identified at least one such problem: Jackhammer. Yes, it’s another fancy name for a vulnerability. This is essentially the Rowhammer attack, launched from an FPGA. In best-case scenarios, they demonstrated an attack speed of three times what could be accomplished on a CPU alone.

Tesla Hack

A very detailed attack on the Tesla Model S WiFi stack caught my attention this week. Published by the Tencent Keen Security Lab, this is a very impressive walk-through of how to compromise the Linux system at the heart of that vehicle.

It starts by knocking the Tesla off whatever WiFi network it’s connected to, and capturing the reconnection. With the information gathered, an attack can be launched against the WiFi chip itself. Once that is compromised, a vulnerability in the Linux wifi driver is triggered to gain execution on that system. It’s worth asking, how many drivers are written to be defensive against the very chip they support? The entire write-up is impressive, go read the whole thing.

Odds, Ends, and TikToks

TikTok is all the rage among the young folk these days. The guys at Checkpoint Research decided to take a look at the app and infrastructure, and found a handful of vulnerabilities.

Cisco made public another round of security goofs. It’s full of flaws like static shared keys and hard coded credentials.

Firefox released an unexpected point release, only a day after a scheduled release. 72.0.1 was pushed out in response to a 0-day being actively exploited. Not much is known about the vulnerability yet, other than Mozilla’s statement that it was a type confusion bug.

 

6 thoughts on “This Week In Security: Camera Feeds, Python 2, FPGAs

  1. > It is quite possible that because of the continued popularity and usage of Python2, a third party will step in and take over maintenance of the language, essentially forking Python. Unless such an event happens, it’s definitely time to migrate away from Python2.

    Such a group has stepped up already over a decade ago, and PyPy will be supporting Python (it’s not called Python 2) indefinitely (in large part because most of their own tooling is based on it).

  2. > how many drivers are written to be defensive against the very chip they support
    This makes me think of “How many OS’es are written to be defensive against the CPU that they are running on” :)

    1. Well – the external chip may be defective for all we know, especially if it has some smarts.
      The CPU – hard to be defensive about that (other than distributing computations over physically separate systems and then checking that results are the same).

Leave a Reply to DanCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.