Connect with us

Gadgets

Buffer overruns, license violations, and bad code: FreeBSD 13’s close call

Published

on

Enlarge / FreeBSD’s core development team, for the most part, does not appear to see the need to update their review and approval procedures.

Aurich Lawson (after KC Green)

At first glance, Matthew Macy seemed like a perfectly reasonable choice to port WireGuard into the FreeBSD kernel. WireGuard is an encrypted point-to-point tunneling protocol, part of what most people think of as a “VPN.” FreeBSD is a Unix-like operating system that powers everything from Cisco and Juniper routers to Netflix’s network stack, and Macy had plenty of experience on its dev team, including work on multiple network drivers.

So when Jim Thompson, the CEO of Netgate, which makes FreeBSD-powered routers, decided it was time for FreeBSD to enjoy the same level of in-kernel WireGuard support that Linux does, he reached out to offer Macy a contract. Macy would port WireGuard into the FreeBSD kernel, where Netgate could then use it in the company’s popular pfSense router distribution. The contract was offered without deadlines or milestones; Macy was simply to get the job done on his own schedule.

With Macy’s level of experience—with kernel coding and network stacks in particular—the project looked like a slam dunk. But things went awry almost immediately. WireGuard founding developer Jason Donenfeld didn’t hear about the project until it surfaced on a FreeBSD mailing list, and Macy didn’t seem interested in Donenfeld’s assistance when offered. After roughly nine months of part-time development, Macy committed his port—largely unreviewed and inadequately tested—directly into the HEAD section of FreeBSD’s code repository, where it was scheduled for incorporation into FreeBSD 13.0-RELEASE.

This unexpected commit raised the stakes for Donenfeld, whose project would ultimately be judged on the quality of any production release under the WireGuard name. Donenfeld identified numerous problems with Macy’s code, but rather than object to the port’s release, Donenfeld decided to fix the issues. He collaborated with FreeBSD developer Kyle Evans and with Matt Dunwoodie, an OpenBSD developer who had worked on WireGuard for that operating system. The three replaced almost all of Macy’s code in a mad week-long sprint.

This went over very poorly with Netgate, which sponsored Macy’s work. Netgate had already taken Macy’s beta code from a FreeBSD 13 release candidate and placed it into production in pfSense’s 2.5.0 release. The forklift upgrade performed by Donenfeld and collaborators—along with Donenfeld’s sharp characterization of Macy’s code—presented the company with a serious PR problem.

Netgate’s public response included accusations of “irrational bias against mmacy and Netgate” and irresponsible disclosure of “a number of zero-day exploits”—despite Netgate’s near-simultaneous declaration that no actual vulnerabilities existed.

This combative response from Netgate raised increased scrutiny from many sources, which uncovered surprising elements of Macy’s own past. He and his wife Nicole had been arrested in 2008 after two years spent attempting to illegally evict tenants from a small San Francisco apartment building the pair had bought.

The Macys’ attempts to force their tenants out included sawing through floor support joists to make the building unfit for human habitation, sawing holes directly through the floors of tenants’ apartments, and forging extremely threatening emails appearing to be from the tenants themselves. The couple fled to Italy to avoid prosecution but were eventually extradited back to the US—where they pled guilty to a reduced set of felonies and served four years and four months each.

Macy’s history as a landlord, unsurprisingly, dogged him professionally—which contributed to his own lack of attention to the doomed WireGuard port.

“I didn’t even want to do this work,” Macy eventually told us. “I was burned out, spent many months with post-COVID syndrome… I’d suffered through years of verbal abuse from non-doers and semi-non-doers in the project whose one big one up on me is that they aren’t felons. I jumped at the opportunity to leave the project in December… I just felt a moral obligation to get [the WireGuard port] over the finish line. So you’ll have to forgive me if my final efforts were a bit half-hearted.”

This admission answers why such an experienced, qualified developer might produce inferior code—but it raises much larger questions about process and procedure within the FreeBSD core committee itself.

How did so much sub-par code make it so far into a major open source operating system? Where was the code review which should have stopped it? And why did both the FreeBSD core team and Netgate seem more focused on the fact that the code was being disparaged than its actual quality?

Code Quality

The first issue is whether Macy’s code actually had significant problems. Donenfeld said that it did, and he identified a number of major issues:

  • Sleep to mitigate race conditions
  • Validation functions which simply return true
  • Catastrophic cryptographic vulnerabilities
  • Pieces of the wg protocol left unimplemented
  • Kernel panics
  • Security bypasses
  • Printf statements deep in crypto code
  • “Spectacular” buffer overflows
  • Mazes of Linux→FreeBSD ifdefs

But Netgate argued that Donenfeld had gone overboard with his negative assessment. The original Macy code, they argued, was simply not that bad.

Despite not having any kernel developers on-staff, Ars was able to verify at least some of Donenfeld’s claims directly, quickly, and without external assistance. For instance, finding a validation function which simply returned true—and printf statements buried deep in cryptographic loops—required nothing more complicated than grep.

Empty validation function

In order to confirm or deny the claim of an empty validation function—one which always “returns true” rather than actually validating the data passed to it—we searched for instances of return true or return (true) in Macy’s if_wg code, as checked into FreeBSD 13.0-HEAD.

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir 'return.*true' . | wc -l
21

This is a small enough number of returns to easily hand-audit, so we then used grep to find the same data but with three lines of code coming immediately before and after each return true:

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir -A3 -B3 'return.*true' .

Among the valid uses of return true, we discovered one empty validation function, in module/module.c:

wg_allowedip_valid(const struct wg_allowedip *wip)
{

 return (true);
}

It’s probably worth mentioning that this empty validation function is not buried at the bottom of a sprawling mass of code—module.c as written is only 863 total lines of code.

We did not attempt to chase down the use of this function any further, but it appears to be intended to check whether a packet’s source and/or destination belongs to WireGuard’s allowed-ips list, which determines what packets may be routed down a given WireGuard tunnel.

Continue Reading

Gadgets

Apple reaches quiet truce over iPhone privacy changes

Published

on

Enlarge / A privacy notice appears on an iPhone 12 under the new iOS 14.5.1 operating system. Developers of an application have to ask for the user’s permission to allow cross-app tracking.

Picture Alliance | Getty Images

Apple has allowed app developers to collect data from its 1 billion iPhone users for targeted advertising, in an unacknowledged shift that lets companies follow a much looser interpretation of its controversial privacy policy.

In May Apple communicated its privacy changes to the wider public, launching an advert that featured a harassed man whose daily activities were closely monitored by an ever-growing group of strangers. When his iPhone prompted him to “Ask App Not to Track,” he clicked it and they vanished. Apple’s message to potential customers was clear—if you choose an iPhone, you are choosing privacy.

But seven months later, companies including Snap and Facebook have been allowed to keep sharing user-level signals from iPhones, as long as that data is anonymised and aggregated rather than tied to specific user profiles.

For instance Snap has told investors that it plans to share data from its 306 million users—including those who ask Snap “not to track”—so advertisers can gain “a more complete, real-time view” on how ad campaigns are working. Any personally identifiable data will first be obfuscated and aggregated.

Similarly, Facebook operations chief Sheryl Sandberg said the social media group was engaged in a “multiyear effort” to rebuild ad infrastructure “using more aggregate or anonymized data”.

These companies point out that Apple has told developers they “may not derive data from a device for the purpose of uniquely identifying it.” This means they can observe “signals” from an iPhone at a group level, enabling ads that can still be tailored to “cohorts” aligning with certain behavior but not associated with unique IDs.

This type of tracking is becoming the norm. Oren Kaniel, the chief executive of AppsFlyer, a mobile attribution platform that works with app developers, said that when his company introduced such a “privacy-centric” tool based on aggregated measurement in July 2020, “the level of pushback that we received from the entire ecosystem was huge.”

But now such aggregated solutions are the default for 95 percent of his clients. “The market changed their minds in a radical way,” he said.

It is not clear whether Apple has actually blessed these solutions. Apple declined to answer specific questions for this article but described privacy as its North Star, implying it was setting a general destination rather than defining a narrow pathway for developers.

Cory Munchbach, chief operating officer at customer data platform BlueConic, said Apple had to stand back from a strict reading of its rules because the disruption to the mobile ads ecosystem would be too great.

“Apple can’t put themselves in a situation where they are basically gutting their top-performing apps from a user-consumption perspective,” she said. “That would ultimately hurt iOS.”

For anyone interpreting Apple’s rules strictly, these solutions break the privacy rules set out to iOS users.

Lockdown Privacy, an app that blocks ad trackers, has called Apple’s policy “functionally useless in stopping third-party tracking.” It performed a variety of tests on top apps and observed that personal data and device information is still “being sent to trackers in almost all cases.”

But the companies aggregating user-level data said the reason apps continue to “leak” information such as a user’s IP address and location was simply because some require such information to function. Advertisers must know certain things such as the user’s language or the device screen size, otherwise the app experience would be awful.

The risk is that by allowing user-level data to be used by opaque third parties so long as they promise not to abuse it, Apple is in effect trusting the very same groups that chief executive Tim Cook has lambasted as “hucksters just looking to make a quick buck.”

Companies will pledge that they only look at user-level data once it has been anonymized, but without access to the data or algorithms working behind the scenes, users won’t really know if their data privacy has been preserved, said Munchbach.

“If historical precedent in adtech holds, those black boxes hide a lot of sins,” she said. “It’s not unreasonable to assume it leaves a lot to be desired.”

© 2021 The Financial Times Ltd. All rights reserved Not to be redistributed, copied, or modified in any way.

Continue Reading

Gadgets

Roku vs. Google drama winds down as companies forge multi-year YouTube deal

Published

on

Enlarge / Roku’s 4K Streaming Stick.

Roku

Roku and Google have arrived at a multi-year deal that will keep the YouTube and YouTube TV apps available on Roku’s devices, Roku announced on Twitter this morning. The agreement comes months after the YouTube TV app was pulled from the Roku Channel Store and just one day before the regular YouTube app would have been removed from the store.

Specific terms of the deal haven’t been announced, including how many years “multi-year” means and whether Roku will begin adding decoding support for the AV1 video codec to its hardware. We also don’t know whether the $65-per-month YouTube TV service will return to the Roku store as its own dedicated app or if it will continue to be rolled into the main YouTube app, as it has been since Google added it there to sidestep Roku’s restrictions in May.

Support for the AV1 codec has been one of the major sticking points between the two companies. The YouTube and YouTube TV apps use AV1 (which is backed by Google, among other companies) to deliver compressed 4K and 8K video streams. But because streaming devices tend to use slower, cheaper processors, they rely on dedicated video decoding hardware to be able to actually decompress and display those video files, and while most of these devices support the commonly used H.265/HEVC codec for high-resolution video streams, fewer support the royalty-free AV1 codec.

Roku has said that adding AV1 support to its devices would “increase consumer costs,” and requiring it for YouTube and YouTube TV support would effectively allow Google to dictate which chips Roku uses in its own products. Google has also accused Roku of using its position in the streaming-device market to secure more favorable terms (Roku’s devices account for a plurality of all streaming in North America, though its market share is lower in other regions). The YouTube and YouTube TV apps may not be able to stream high-resolution video on devices without AV1 support, though having those apps available in Roku’s store in any capacity is probably better for both companies than allowing them to be pulled entirely.

Continue Reading

Gadgets

Razer’s RGB smartphone cooler attaches to iPhones with MagSafe

Published

on

Enlarge / Razer Phone Cooler Chroma.

PC gamers know about heat. When you’re in the middle of an intense in-game battle, the last thing you want is for your computer to start acting up because your CPU or GPU got too hot. That’s why gamers and other extreme users rely on products like CPU coolers and liquid cooling systems. You probably haven’t been as concerned about your smartphone’s thermals while playing Candy Crush on your iPhone. Nevertheless, Razer released a new product, the Phone Cooler Chroma, on Tuesday to ensure your smartphone doesn’t overheat the next time you use it for gaming.

Of course, mobile gaming has grown beyond the likes of Candy Crush and Angry Birds. Razer (and some other vendors) have been trying to make mobile gaming a serious thing for a while. The company’s efforts are mostly focused on controllers, like the Razer Kishi, that attach to your smartphone. There’s also Razer’s finger sleeve for mobile gaming.

The Phone Cooler Chroma released Tuesday has a different purpose. Compatible with both iPhone and Android phones (it supports “most smartphones,” Razer’s product page claims), the product is meant to help keep your phone cool while it’s pushing those frames.

Interestingly, the fan takes advantage of Apple’s MagSafe, allowing you to attach the cooler magnetically. That’s convenient, but it also means the cooler won’t sit directly above the phone’s SoC.

If you don’t have a MagSafe-compatible phone, you can opt for the version with a universal clamp.

Clamp option.

We don’t know how adjustable the cooler is, but Razer says it works with phones that are 2.64-3.46 inches (67-88 mm) wide.

Staying cool?

1. RGB, 2. cover, 3. fan, 4. heatsink, 5. Peltier cooling tile, 6. cooling plate.
Enlarge / 1. RGB, 2. cover, 3. fan, 4. heatsink, 5. Peltier cooling tile, 6. cooling plate.

A cooling plate sits on the back cover and is topped by an electronic tile that uses Peltier cooling, also known as thermoelectric cooling, to transfer heat. The next layer is a heatsink under a seven-bladed fan spinning at up to 6,400 revolutions per minute, adjustable via Bluetooth. Razer says the cooler can stay at 30 dB.

On top of the fan lies a cover with air vents, and—of course—RGB lighting. Does the lighting help your phone stay cool? Absolutely not. But it almost wouldn’t be a Razer product without it. The gaming brand even put RGB on its N95 mask, so Chroma lighting here is no surprise.

RGB feels like a Razer requirement.
Enlarge / RGB feels like a Razer requirement.

There are 12 RGB LEDs in the cover, and each can be set to its own color and effect.

You’ll need a USB-C cable to power the Phone Cooler Chroma. The cooler comes with a 4.9-foot (1.5 m) USB-C to USB-C cable, but this seems like it could be burdensome when gaming on the go, as a mobile gamer is inclined to do.

Power over USB-C required.
Enlarge / Power over USB-C required.

Razer didn’t make any claims about how much cooler the product will keep your phone’s components. Unlike a CPU cooler, this cooler doesn’t come into direct contact with the processor, and it doesn’t have any exhaust vents to work with as some laptop fan coolers do. So the heat transfer from the actual SoC may be limited. Hardcore mobile gamers can find out for themselves for $60.

Ars Technica may earn compensation for sales from links on this post through affiliate programs.

Continue Reading

Trending