News

3615 Articles

This Week In Security: Perl.com, The Great Suspender, And Google’s Solution

February 5, 2021 by 46 Comments

Perl has been stolen. Well, perl.com, at least. The perl.com domain was transferred to a different registrar on January 27, without the permission of the rightful owner. The first to notice the hack seems to have been [xtaran], who raised the alarm on a Reddit thread. The proper people quickly noticed, and started the process of getting control of the domain again. It seems that several other unrelated domains were also stolen in the same attack.

I’ve seen a couple of theories tossed around about how the domains were stolen. With multiple domains being moved, it initially seemed that the registrar had been compromised in some way. One of the other victims was told that a set of official looking documents had been supplied, “proving” that the attacker was the rightful owner of the domain. In any case, the damage is slowly being unwound. Perl.com is once again in the proper hands, evidenced by the proper SSL certificate issued back in December.

The Great Suspender, Suspended

I was greeted by a particularly nasty surprise on Thursday of this week. One of the Chrome extensions I’ve come to rely on was removed by Google for containing malware. The Great Suspender automatically hibernates unused tabs, saving ram and processor cycles that would otherwise be spent on those 150 open tabs that should really be bookmarks. What happened here?

I’ll point out that I’m extremely careful about installing extensions. It’s code written by a third party, often very difficult to inspect, and can view and modify the sites you visit. You can manage what sites an extension has access to, but for a tool like the Suspender, it essentially needs access to all of them. The solution is to use open source extensions, right? “Well yes, but actually no.” Suspender is open source, after all. The link above goes to the project’s Github page. In that repo you’ll find an announcement from last year, that the founding developer is finished with the project, and is selling the rights to an unknown third party, who took over maintainership. If this sounds familiar, there are echoes of the event-stream debacle.

It’s not clear exactly what malicious behavior Google found that led to the extension being pulled, but a more careful look at the project reveals that there were potential problems as early as October of 2020. An addition to the extension introduced execution of code from a remote server, never a good idea. For what it’s worth, the original maintainer has made a statement, defending the new owners, and suggesting that this was all an innocent mistake.

The lesson here? It’s not enough to confirm that an extension checks the “open source” box. Make sure there is an active community, and that there isn’t a 6 month old bug report detailing potentially malicious activity.

Libgcrypt

It’s not everyday you see a developer sending out a notice that everyone should stop using his latest release. That’s exactly what happened with Libgcrypt 1.9.0. Our friends over at Google’s Project Zero discovered an extremely nasty vulnerability in the code. It’s a buffer overflow that happens during the decryption process, before even signature verification. Since libgcrypt is used in many PGP implementations, the ramifications could be nasty. Receive an encrypted email, and as soon as your client decrypts it, code is executing. Thankfully, an update that fixes the issue has already been released.

Android Botnet

A new botnet is targeting Android devices in a peculiar way — looking for open ADB debug ports exposed to the Internet. Google makes it very clear that ADB over the network is insecure, and should only be used for development purposes, and on controlled networks. It’s astounding that so many vendors ship hardware with this service exposed. Beyond that, it’s surprising that so many people give their Android devices public IP addresses (or IPv6 addresses that aren’t behind a firewall). The botnet, named Matryosh, has another unique feature, as it uses Tor for command and control functions, making it harder to track.

Google Solution to Open-Source Security

Google published a post on their open source blog, giving an overview for their new framework for the security of open source projects. “Know, Prevent, Fix” is their name for the new effort, and it must have been written by management, because it’s full of buzzwords. The most interesting elements are their goals for critical software. They identify problems like the ability of a single maintainer to push bad code into a project, and how anonymous maintainers is probably a bad idea. It will be interesting to see how these ideas develop, and how Google will help open source communities implement them.

Microsoft in My Pi

And finally, I was amused by an article lamenting the inclusion of the VSCode repository in the default Raspberry Pi OS images. He does raise a couple legitimate points. Amont them, you do send a ping to Microsoft’s servers every time you check for new updates.

The larger point is that the official VSCode binaries have telemetry code added to them — code that isn’t in the open source repository. What is it doing? You don’t know. But it probably violates European law.

Want to use VSCode, but not interested in shipping info off to Microsoft? VSCodium is a thing.

This Isn’t Your Father’s Yellow Card

February 1, 2021 by 59 Comments

As the global vaccination effort rolls out in many countries, people will increasingly be required to provide evidence for various reasons, especially travelers. Earlier this month a coalition which includes Microsoft, the Mayo Clinic, Oracle, MITRE, and others announced an effort to establish digital vaccination records called the Vaccination Credential Initiative (VCI). This isn’t going to be a brand new thing, but rather an initiative to provide digital proof-of-vaccination to people who want it, using existing open standards:

  • Verifiable Credentials, per World Wide Web Consortium Recommendation (VC Data Model 1.0)
  • Industry standard format and security, per the Health Level Seven International (HL7) FHIR standard

In addition, the World Health Organization formed the Smart Vaccination Certificate Working Group in December. Various other countries and organizations also have technical solutions in the works or already deployed. If a consensus doesn’t form soon, we can see this quickly becoming a can of worms. Imagine having to obtain multiple certifications of your vaccination because of non-uniform requirements between countries, organizations, and/or purposes.

Older readers and international travelers may be wondering, “don’t we already have a vaccination card system?” Indeed we do: the Carte Jaune or Yellow Card. The concept of a “vaccination passport” was conceived and agreed upon at the International Sanitary Convention for Aerial Navigation in 1933. Over the years the names and diseases of interest have changed, but since 2007 it has been formally called the International Certificate of Vaccination or Prophylaxis (ICVP). In recent times, yellow fever was the only vaccination of interest to travelers, but other vaccinations or booster shots can be recorded as well. One problem with the paper Yellow Card is that it is ridiculously easy to forge. Nefarious or lazy travelers could download it from the WHO site, print it on appropriate yellow card stock, and forge a doctor’s signature. The push for a more secure ICVP is not completely unreasonable.

Reading the instructions on the Yellow Card brings up a couple of interesting points:

  • This certificate is valid only if the vaccine or prophylaxis used has been approved by the World Health Organization — Currently the Pfizer vaccine is the only one to be approved by WHO, and even that is only an emergency approval. If you receive a non-Pfizer vaccination, what then?
  • The only disease specifically designated in the International Health Regulations (2005) for which proof of vaccination or prophylaxis may be required as a condition of entry to a State Party, is yellow fever — This one is interesting, and suggests that member states cannot require proof of Covid19 vaccination as an entry requirement, a situation that will no doubt be quickly revised or ignored.

Note: This writeup is about vaccinations, not about immunity. While immunity certificates have been used from time to time throughout modern history, the concept of an international immunity passport is not well established like the ICVP.

This Week In Security: Sudo, Database Breaches, And Ransomware

January 29, 2021 by 27 Comments
We couldn't resist, OK?
Obligatory XKCD

Sudo is super important Linux utility, as well as the source of endless jokes. What’s not a joke is CVE-2021-3156, a serious vulnerability around incorrect handling of escape characters. This bug was discovered by researchers at Qualys, and has been in the sudo codebase since 2011. If you haven’t updated your Linux machine in a couple days, you may very well be running the vulnerable sudo binary still. There’s a simple one-liner to test for the vulnerability:

sudoedit -s '\' `perl -e 'print "A" x 65536'`

In response to this command, my machine throws this error, meaning it’s vulnerable:

malloc(): corrupted top size
Aborted (core dumped)

To understand the problem with sudo, we have to understand escape characters. It really boils down to spaces in file and folder names, and how to deal with them. You want to name your folder “My Stuff”? That’s fine, but how do you interact with that directory name on the command line, when spaces are the default delimiter between arguments? One option is to wrap it in quotation marks, but that gets old in a hurry. The Unix solution is to use the backslash character as an escape character. Hence you can refer to your fancy folder as My\ Stuff. The shell sees the escape character, and knows to interpret the space as part of the folder name, rather than an argument separator. Escape characters are a common vulnerability location, as there are plenty of edge cases. Continue reading “This Week In Security: Sudo, Database Breaches, And Ransomware” →

Fire In The Palm Of Your Hand

January 29, 2021 by 15 Comments

For as long as super-heroes have existed, they have inspired hacker projects. For [Everett Bradford], emulating the character Pyro from X-Men has been an on and off project for the last decade. His latest version, Pyro System V4, integrates quite a bit of control electronics to give the rather convincing effect of mind-controlled fire in the palm of his hand. (Video, embedded below.)

The system is a motor-actuated slider strapped to [Everett]’s forearm, which pushes a pivoting end-effector with an integrated butane burner into the palm of his hand. The slider runs on 4 mm linear bearings actuated by a small geared DC motor using cables. The end effector is spring-loaded to push it into the palm and integrates a high voltage ignition arc generator circuit, nozzle, and capacitive activation button.

The butane gas canister and the valve was cannibalized from a small blow torch lighter, and the valve is actuated by another geared DC motor. The valve actuator, slide actuator, and end-effector hinge all integrate position feedback via hall effect sensors and magnets. The sensor in the hinge allows the slide to actively correct for the angle of the user’s wrist, keeping the end effector in the middle of the palm.

The control circuit is split into two parts. One PIC16 microcontroller runs all the motion control and position sensing, while a PIC18 connected to a small touch screen handles user interface, control parameters, and ignition. The touch screen proved especially useful for control parameters during development without needing to connect to a laptop.

Some of [Everett]’s previous version had a much more impressive (and dangerous) flame but was also very bulky. We think this latest version strikes a pretty good balance regarding compactness and achieving convincing illusion.

[Colin Furze] is another name commonly associated with fire-breathing contraptions, but they have a proven history of landing him in hospital.

Continue reading “Fire In The Palm Of Your Hand” →

Google Loon’s Internet Balloons Come Back To Earth After A Decade In The Stratosphere

January 28, 2021 by 47 Comments

After a journey of a decade, what started as Project Loon by Google is no more. Promoted as a way to bring communications to the most remote parts of the globe, it used gigantic, high-altitude balloons equipped with communication hardware for air to ground, as well as air to air communication, between individual balloons. Based around LTE technology, it would bring multiple megabit per second data links to both remote areas and disaster zones.

Seven years into its development, Loon became its own company (Loon LLC), and would provide communications to some areas of Kenya, in addition to Sri Lanka in 2015 and Puerto Rico in 2017 after Hurricane Maria. Three years later, in January of 2021, it was announced that Loon LLC would be shutting down operations. By that point it had become apparent that the technology would not be commercially viable, with alternatives including wired internet access having reduced the target market.

While the idea behind Loon sounds simple in theory, it turns out that it was more complicated than just floating up some weather balloon with LTE base stations strapped to them.

Continue reading “Google Loon’s Internet Balloons Come Back To Earth After A Decade In The Stratosphere” →

What’s The Deal With Chromium On Linux? Google At Odds With Package Maintainers

January 26, 2021 by 152 Comments

Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.

A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.

To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.

Unhappy with the idea of giving users a semi-functional browser, the Chromium maintainers for several distributions such as Arch Linux and Fedora have said they’re considering pulling the package from their respective repositories altogether. With a Google representative confirming the change is coming regardless of community feedback, it seems likely more distributions will follow suit.

Continue reading “What’s The Deal With Chromium On Linux? Google At Odds With Package Maintainers” →

NASA Challenge Offers Prizes For Sprouting Astronaut Food Systems

January 25, 2021 by 53 Comments

Humans have unfortunately not yet evolved the ability to photosynthesize or recharge from an electricity source, which is why astronauts well into the future of spaceflight will need to have access to food sources. Developing ways to grow food in space is the focus of the new Deep Space Food Challenge that was just launched by NASA and Canada’s Space Agency (CSA).

With a total of twenty $25,000 USD prizes for US contestants and ten $30,000 CAD prizes for the Canucks in Phase 1 of the challenge, there’s some financial incentive as well. In Phase 2, the winning teams of the concept phase have to show off their kitchen skills, and in the final Phase 3 (deadline by Fall 2023) the full food growing system has to be demonstrated.

The possible systems here would likely involve some kind of hydroponics, aeroponics or even aquaponics, to save the weight of lugging kilograms of soil into space. None of this is truly new technology, but cramming it into a package that would be able to supply a crew of four with enough food during a three-year mission does seem fairly challenging.

The NASA rules are covered in their Phase 1 Rules PDF document. While international teams are also welcome to compete, they cannot receive any prizes beyond recognition, and Chinese citizens or companies with links to China are not to allowed to compete at all.