This Week In Security: Leaking Partial Bits, Apple News, And Overzealous Contact Tracing

May 29, 2020 by Jonathan Bennett 11 Comments

Researchers at the NCCGroup have been working on a 5-part explanation of a Windows kernel vulnerability, targeting the Kernel Transaction Manager (KTM). The vulnerability, CVE-2018-8611, is a local privilege escalation bug. There doesn’t seem to be a way to exploit this remotely, but it is an interesting bug, and NCCGroup’s work on it is outstanding.

They start with a bit of background on what the KTM is, and why one might want to use it. Next is a handy guide to reverse engineering Microsoft patches. From there, they describe the race condition and how to actually exploit it. They cover a wide swath in the series, so go check it out.

Left4Dead 2

Just a reminder that bugs show up where you least expect them, [Hunter Stanton] shares his story of finding a code execution bug in the popular Valve game, Left4Dead 2. Since the game’s code isn’t available to look at, he decided to go the route of fuzzing. The specific approach he took was to fuzz the navigation mesh data, part of the data contained in each game map. Letting the Basic Fuzzing Framework (BFF) run for three days turned up a few possible crashes, and the most promising turned out to have code execution potential. [Hunter] submitted the find through Valve’s HackerOne bug bounty program, and landed a cool $10k bounty for his trouble.

While it isn’t directly an RCE, [Hunter] does point out that malicious mesh data could be distributed with downloadable maps on the Steam workshop. Alternatively, it should be possible to set up a fake game server that distributes the trapped map. Continue reading “This Week In Security: Leaking Partial Bits, Apple News, And Overzealous Contact Tracing” →

Raspberry Pi 4 Gets Its 8 Gigs

May 28, 2020 by Mike Szczys 121 Comments

What began as a rumor becomes reality. This morning [Eben Upton] announced that the newest flavor of the Raspberry Pi 4 comes with 8 gigabytes of RAM and a sticker price of $75, roughly twice that of the base model which is now pegged at 2 GB of ram.

Originally released on June 23rd of last year, the Pi 4 came with three different options for 1, 2, or 4 GB of memory. But just a few days later, Hackaday reported on an Easter egg in the user guide that referenced an 8 GB option.

So why didn’t this version get released in 2019? That’s the crazy thing about this story. In the announcement [Eben] mentions that the Pi’s design is capable of addressing up to 16 GB of LPDDR4 SDRAM (we say bring it, but that’s a discussion for a different day). It took a year to get here because there wasn’t a source available for this 8 gig version until Micron began manufacturing the chip earlier this year.

Also addressed in this announcement is a looming changeover that was bound to happen eventually: the move from 32-bit to 64-bit operating systems on the Pi. While a 32-bit image can access all of this larger memory across multiple process, it can’t devote more than 3 GB to a single Linux process because of address space limitations. Simply put, you need more bits to access the higher addresses. Moving to a 64-bit system accomplishes that, something you can do by running unofficial builds on the Pi, but the official build didn’t support it until today’s announcement of a 64-bit beta image.

This is inevitable, not purely because of this memory limitation, but because we’ve seen examples where the juggernaut of Linux development has its own eye on a 64-bit future. Official images for Raspberry Pi have always been 32-bits, and remain so for now, but the wind is beginning to blow for this and future hardware offerings that are bumping up against limitations. Along with the news of this impending architecture switch over, the official operating system has also gotten a name change: Raspbian will henceforth be known as Raspberry Pi OS.

When [Jenny List] first reported on the 8 GB rumors last June, she speculated that today’s announcement would happen on February 29th of this year. Why the leap day? It happened to be the 8th birthday of Raspberry Pi and synced up nicely with an 8 GB surprise. Today’s announcement drops the morsel of trivia that the foundation was indeed planning on that date, but missed it by three months due to supply chain disruption associated with the coronavirus pandemic that prevented them from sourcing all the parts necessary for the new power supply design included in this revision.

We’d love to hear your thoughts on this move. Do you need 8 GB on your Pi, and does the 3 GB limitation of a 32-bit kernel matter to you? Let us know in the comments below.

Coronavirus Testing: CRISPR Technology Set To Streamline Viral Testing

May 27, 2020 by Dan Maloney 3 Comments

If we could run back 2020 to its beginning and get a do-over, chances are pretty good that we’d do a lot of things differently. There’s a ton of blame to go around on COVID-19, but it’s safe to say that one of the biggest failures of this whole episode has been the lack of cheap, quick, accurate testing for SARS-CoV-2, the virus behind the current pandemic. It’s not for lack of information; after all, Chinese scientists published the sequence of the viral genome very early in the pandemic, and researchers the world over did the same for all the information they gleaned from the virus as it rampaged around the planet.

But leveraging that information into usable diagnostics has been anything but a smooth process. Initially, the only method of detecting the virus was with reverse transcriptase-polymerase chain reaction (RT-PCR) tests, a fussy process that requires trained technicians and a well-equipped lab, takes days to weeks to return results, and can only tell if the patient has a current infection. Antibody testing has the potential for a quick and easy, no-lab-required test, but can only be used to see if a patient has had an infection at some time in the past.

What’s needed as the COVID-19 crisis continues is a test with the specificity and sensitivity of PCR combined with the rapidity and simplicity of an antibody test. That’s where a new assay, based on the latest in molecular biology methods and dubbed “STOPCovid” comes in, and it could play a major role in diagnostics now and in the future.

Continue reading “Coronavirus Testing: CRISPR Technology Set To Streamline Viral Testing” →

DMCA Takedown Issued Over Casio Code That Wasn’t

May 24, 2020 by Jenny List 97 Comments

Earlier this month, we posted coverage of an ingenious calculator hack that took a Casio calculator and put an ESP8266 module and an OLED display in the space occupied by its solar cell. Controlled by a pair of unobtrusive Hall effect devices, the calculator could have been used as an ingenious cheating device but was to us the epitome of a well-executed hack. We may have liked it but it seems the folks at Casio didn’t, because they’ve issued a DMCA takedown notice for the project’s GitHub repository.

Editor’s Update: [Tom Fleet] reports that GitHub has completed the DMCA review and found the code repo does not infringe on Casio’s IP. However, it appears the copyright claim on the YouTube video has not been resolved and that video remains unavailable. However, that video is still available on the Internet Archive.

This is a picture of Barbra Streisand, who might almost be the patron saint of unintended consequences. Unknown author / Public domain.

We’re not lawyers, but if you’d care to visit our original coverage and watch the video in full, you’ll see that the ESP does not in any way tap into the calculator’s functions. The epoxy blob over the Casio processor is intact and no wires connect to the calculator mainboard, so it is difficult to imagine how any Casio code could have found its way into a repository full of ESP8266 code for the Arduino IDE. A quick search for “Hack-Casio-Calculator” on GitHub, at the time of publishing, turned up the relevant code despite Casio’s takedown, and we can’t see what they’re on about. Maybe you can?

Over the years there have been many attempts to use the DMCA on projects in our community. Some have been legitimate, others have been attempts to suppress exposure of woeful security, and still more have been laughably absurd. This one seems to us to edge into the final category, because it is difficult to see how the project described could contain any Casio code at all. It would be entirely legitimate to issue a DMCA takedown had the epoxy blob been removed and Casio’s code been retrieved from the calculator chip (and we’d certainly cover that story!), but as far as we can see taking a scalpel to a calculator’s case and stuffing a module behind the solar panel window does not come close.

It’s evident that Casio do not like the idea of one of their calculators being turned into a cheating device, and we understand why that might be the case. But to take the DMCA route has served only to bring more publicity to the affair, and those of us with long memories know that this can only lead to one conclusion.

Thanks [Tom] and others for the tip.

Microsoft Releases The Source Code You Wanted Almost 30 Years Ago

May 22, 2020 by Al Williams 66 Comments

In the late 1970s and early 1980s, if you had a personal computer there was a fair chance it either booted into some version of Microsoft Basic or you could load and run Basic. There were other versions, of course, especially for very small computers, but the gold standard for home computer Basic was Microsoft’s version, known then as GW-Basic. Now you can get the once-coveted Microsoft Basic source code for the 8086/8088 directly from Microsoft in the state you would have found it in 1983. They put up a read only GW-BASIC repository, presumably to stop a flood of feature requests for GPU acceleration.

You might wonder why they would do this? It is certainly educational, especially if you are interested in assembly language. For historical reasons, you might want to get a copy you could modify, too, for your latest retrocomputer project.

There are a few tidbits of interest. Some of the source is marked that it was translated. Apparently, Microsoft had a master implementation for some processor — real or imagined — and could translate from that code to 8088, Z-80, 6502, or any other processor they wanted to target.

From what we understand, GW-Basic was identical to IBM’s BASICA, but didn’t require certain IBM PC ROMs to operate. Of course, BASICA, itself, came from MBASIC, Microsoft’s CP/M language that originated with Altair Basic. A long lineage that influenced personal computers for many years. On a side note, there’s debate on what the GW stands for. Gee-Whiz is a popular vote, but it could stand for ‘Gates, William’, Greg Whitten (an early Microsoft employee), or Gates-Whitten. The source code doesn’t appear to answer that question.

We did enjoy the 1975 copyright message, though:

ORIGINALLY WRITTEN ON THE PDP-10 FROM
FEBRUARY 9 TO APRIL 9 1975

BILL GATES WROTE A LOT OF STUFF.
PAUL ALLEN WROTE A LOT OF OTHER STUFF AND FAST CODE.
MONTE DAVIDOFF WROTE THE MATH PACKAGE (F4I.MAC).

It wasn’t long ago that Microsoft released some old versions of MSDOS. If you have the urge to write some Basic, you might pass on GW-Basic and try QB64, instead.

GW-Basic Disk and Manual photo by [Palatinatian] CC-SA-4.0.

Radio’s Sordid History Of Being Blamed For Everything

May 22, 2020 by Jenny List 101 Comments

In the surreal world of a pandemic lockdown, we are surrounded by news stories that defy satire. The idea that 5G cellular networks are to blame for the COVID-19 outbreak and a myriad other ills has the more paranoid corners of social media abuzz with concerned citizens leaping upon random pieces of street furniture as potential 5G infrastructure.

The unanimous advice of the world’s scientists, doctors, and engineers that it is inconceivable for a phone technology to cause a viral outbreak. Amusingly, 5G has not yet been rolled out to some of the places where this is happening. But with conspiracy theory, fact denial only serves to reinforce the idea, however misguided. Here at Hackaday we have already ventured into the technical and scientific side of the story, but there is another side to it that leaves the pandemic behind and reaches back over the decades. Fear of new technology and in particular radio is nothing new, it stretches back almost as long as the public has had access to it.

Continue reading “Radio’s Sordid History Of Being Blamed For Everything” →

This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More

May 22, 2020 by Jonathan Bennett 9 Comments

Another DDOS amplification technique has just recently been disclosed, NXNSAttack (technical paper here) that could be used against DNS servers.

We’ve covered amplification attacks before. The short explanation is that some UDP services, like DNS, can be abused to get more mileage out of a DDoS attack. The attacking machined send messages like this: “Hello Google DNS, This is the Hackaday server. Can you send me a really big DNS response packet?” If the DNS response is bigger than the request, then the overall attack is bigger as a result. The measure of effectiveness is the amplification factor. For every byte of DDoS sent by attacking machines, how much many bytes are actually sent to the victim machine? Mirai, for example, had an amplification factor of something around 2.6.

NXNSAttack has a theoretical per-byte amplification factor of 163. That’s not a missed decimal point, this has the potential to be quite the nasty problem. Continue reading “This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More” →