[As] a result of our order, no new Huawei or ZTE equipment can be approved. And no new Dahua, Hikvision, or Hytera gear can be approved unless they assure the FCC that their gear won’t be used for public safety, security of government facilities, & other national security purposes.
There is even the potential that previously approved equipment could have its authorization pulled. The raw FCC documents are available, if you really wish to wade through them. What’s notable is that two diametrically opposed US administrations have both pushed for this ban. It would surely be interesting to get a look at the classified reports detailing what was actually found. Maybe in another decade or two, we can make a Freedom of Information Act request and finally get the full story.
Ready for more speculative execution news? Hope so, because both Intel and AMD are in the news this week.
The first story is Load Value Injection, a different approach to reading arbitrary memory. Rather than try to read protected memory, LVI turns that on its head by injecting data into a target’s data. The processor speculatively executes based on that bad data, eventually discovers the fault, and unwinds the execution. As per other similar attacks, the execution still changes the under-the-hood state of the processor in ways that an attacker can detect.
What’s the actual attack vector where LVI could be a problem? Imagine a scenario where a single server hosts multiple virtual machines, and uses Intel’s Secure Guard eXentensions enclave to keep the VMs secure. The low-level nature of the attack means that not even SGX is safe.
AMD also found itself on the receiving end of a speculative execution attack (PDF original paper here). Collide+Probe and Load+Reload are the two specific attacks discovered by an international team of academics. The attacks are based around the reverse-engineering of a hash function used to speed up cache access. While this doesn’t leak protected data quite like Spectre and Meltdown, it still reveals internal data from the CPU. Time will tell where exactly this technique will lead in the future.
To really understand what’s going on here, we have to start with the concept of a hash table. This idea is a useful code paradigm that shows up all over the place. Python dictionaries? Hash tables under the hood.
Imagine you have a set of a thousand values, and need to check whether a specific value is part of that set. Iterating over that entire set of values is a computationally expensive proposition. The alternative is to build a hash table. Create an array of a fixed length, let’s say 256. The trick is to use a hash function to sort the values into this array, using the first eight bits of the hash output to determine which array location each value is stored in.
When you need to check whether a value is present in your set, simply run that value through the hash function, and then check the array cell that corresponds to the hash output. You may be ahead of me on the math — yes, that works out to about four different values per array cell. These hash collisions are entirely normal for a hash table. The lookup function simply checks all the values held in the appropriate cell. It’s still far faster than searching the whole table.
AMD processors use a hash table function to check whether memory requests are present in L1 cache. The Takeaway researchers figured out that hash function, and can use hash collisions to leak information. When the hash values collide, the L1 cache has two separate chunks of memory that need to occupy the same cache line. It handles this by simply discarding the older data when loading the colliding memory. An attacker can abuse this by measuring the latency of memory lookups.checking
If an attacker knows the memory location of the target data, he can allocate memory in a different location that will be stored in the same cache line. Then by repeatedly loading his allocated memory, he knows whether the target location has been accessed since his last check. What real world attack does that enable? One of the interesting ones is mapping out the memory layout of ASLR/KASLR memory. It was also suggested that Takeaway could be combined with the Spectre attack.
There are two interesting wrinkles to this story. First, some have pointed out the presence of a thank-you to Intel in the paper’s acknowledgements. “Additional funding was provided by generous gifts from Intel.” This makes it sound like Intel has been funding security research into AMD processors, though it’s not clear what exactly this refers to.
Lastly, AMD’s response has been underwhelming. At the time of writing, their official statement is that “AMD believes these are not new speculation-based attacks.” Now that the paper has been publicly released, that statement will quickly be proven to be either accurate or misinformed.
Closed Source Privacy?
The Google play store and iOS app store is full of apps that offer privacy, whether it be a VPN, adblocker, or some other amazing sounding application. The vast majority of those apps, however, are closed source, meaning that you have little more than trust in the app publisher to ensure that your privacy is really being helped. In the case of Sensor Tower, it seems that faith is woefully misplaced.
A typical shell game is played, with paper companies appearing to provide apps like Luna VPN and Adblock Focus. While technically providing the services they claim to provide, the real aim of both apps is to send data back to Sensor Tower. When it’s possible, open source is the way to go, but even an open source app can’t protect you against a malicious VPN provider.
[Robert Graham] thought the whole story was fishy, and decided to write about it. He makes two important points. First, the Wall Street Journal article cites anonymous US officials. In his opinion, this is a huge red flag, and means that the information is either entirely false, or an intentional spin, and is being fed to journalists in order to shape the news. His second point is that Huawei’s redefinition of government-mandated backdoors as “front doors” takes the line of the FBI, and the Chinese Communist Party, that governments should be able to listen in on your communications at their discretion.
Graham shares a story from a few years back, when his company was working on Huawei brand mobile telephony equipment in a given country. While they were working, there was an unspecified international incident, and Graham watched the logs as a Huawei service tech remoted into the cell tower nearest the site of the incident. After the information was gathered, the logs were scrubbed, and the tech logged out as if nothing had happened.
Did this tech also work for the Chinese government? The NSA? The world will never know, but the fact is that a government-mandated “front door” is still a back door from the users’ perspective: they are potentially being snooped on without their knowledge or consent. The capability for abuse is built-in, whether it’s mandated by law or done in secret. “Front doors” are back doors. Huawei’s gear may not be dirtier than anyone else’s in this respect, but that’s different from saying it’s clean.
Abusing Regex to Fool Google
For his work, [xdavidhu] was awarded $6,000 because this bit of ugly regex is actually used in quite a few places throughout Google’s infrastructure.
SMBv3 Wormable Flaw
Microsoft’s SMBv3 implementation in Windows 10 and Server 2019 has a vulnerability in how it handles on-the-fly compression, CVE-2020-0796. A malicious packet using compression is enough to trigger a buffer overflow and remote code execution. It’s important to note that this vulnerability doesn’t required an authenticated user. Any unpatched, Internet-accessible server can be compromised. The flaw exists in both server and client code, so an unpatched Windows 10 client can be compromised by connecting to a malicious server.
There seems to have been a planned coordinated announcement of this bug, corresponding with Microsoft’s normal Patch Tuesday, as both Fortinet and Cisco briefly had pages discussing it on their sites. Apparently the patch was planned for that day, and was pulled from the release at the last moment. Two days later, on Thursday the 12th, a fix was pushed via Windows update. If you have Windows 10 machines or a Server 2019 install you’re responsible for, go make sure it has this update, as proof-of-concept code is already being developed.
Mobile phones are the photography tool for most of us, but they are a blunt tool. If you love astrophotography, you buy a DSLR and a lens adapter. Infrared photography needs camera surgery or a special unit. If you want to look closer to home, you may have a microscope with a CCD. Your pocket computer is not manufactured for microscopy, but that does not mean it cannot be convinced. Most of us have held our lens up to the eyepiece of some binoculars or a microscope, and it sort of works, but it is far from perfect. [Benedict Diederich] and a team are proving that we can get darn beautiful images with a microscope, a phone holder, and some purpose-built software on an Android phone with their cellSTORM.
The trick to getting useful images is to compare a series of pictures and figure out which pixels matter and which ones are noisy. Imagine someone shows you grainy nighttime footage from an outdoor security camera. When you pause, it looks like hot garbage, and you can’t tell the difference between a patio chair and a shrubbery. As it plays, the noisy pixels bounce around, and you figure out you’re looking at a spruce bush, and that is roughly how the software parses out a crisp image. At the cost of frame rate, you get clarity, which is why you need a phone holder. Some of their tests took minutes, so astrophotography might not fare as well.
Back in October 2018, a bombshell rocked the tech industry when Bloomberg reported that some motherboards made by Supermicro had malicious components on them that were used to spy or interfere with the operation of the board, and that these motherboards were found on servers used by Amazon and Apple. We covered the event, looking at how it could work if it were true. Now seven months have passed, and it’s time to look at how things shook out.
[Emil Kalstø] has a pretty solid remote control car. We don’t mean a little car with a handheld remote you can drive around the neighborhood. [Emil’s] car has a camera and a cell phone so that it can go anywhere there’s 3G or 4G networking available.
The video (see below) shows the results (along with [Emil’s] little brother acting as a safety officer). The video offers tantalizing detail you might find useful if you want to reproduce a similar vehicle. However, it stops short of providing complete details.
The two batteries onboard will power the vehicle for over 20 hours of continuous use. The 30W motor is reduced with a chain drive to go about “walking speed.” There’s a Raspberry Pi with a Huawei 3G USB dongle onboard and [Emil] uses an XBox controller to do the steering from the warmth of his living room. Of course, a Pi can’t handle a big motor like that directly, so a Phidgets USB motor controller does the hard work. The software is written using Node.js.
The camera mount can swivel 230 degrees on a servo so that the operator can scan the road ahead. The video mentions that steering the car required a heavy-duty servo with metal gears (an earlier attempt with nylon gears didn’t work out).
Overall, it looks like a solid build. We hope [Emil] will share code and more details soon. If you can’t wait (and your insurance is paid up), you might have a go at an even bigger car. Surprisingly, there’s more than one example of that.