43 comments
I remember when I was doing iOS/macOS security research back in 2015 and I though to myself "I bet core audio has bugs.." but never really looked into them because my thinking was they wouldn't have been too too useful unless you can get someone to open an audio file... But great work.
When I click this link my work's firewall blocks me, asking if I want to proceed to:
http://gambling.com ?url=https://blog.noahhw.dev/posts/cve-2025-31200/
Do you have an extensions installed that might be doing this?
Is there a typo in the code block for the `Process` function near the end of the post? Lines 13-15 have the following loop:
while (remapVec[remapStartIndex] >= index) { // Follow the 'cycle'
index = remapVec[remapStartIndex];
}
The authors probably intended to write:
index = remapVec[index];
I’d be really frustrated if my device was compromised by an esoteric audio format that I had no intention of ever listening to.
If these parsers can’t run inside an isolated process, perhaps they shouldn’t be enabled at all?
> I’d be really frustrated if my device was compromised by an esoteric audio format that I had no intention of ever listening to.
Users get even more frustrated when they want to play something and it does not work. Security is always a usability trade-off.
There is also an argument to be made that it is better for Apple to introduce a few bugs adding support for viewing/playing/etc random things than end users googling "how to play X" and downloading whatever app appears first in the results.
Remember the good 'ol days when everyone had Adobe Acrobat installed so they could open PDFs and it had a new 0day every month? Then one day Chrome added PDF.js and exploitation in the wild dropped off as people stopped downloading shitware to fill out rental applications.
pdf.js was a Mozilla experiment.
We know how to provably do Wrangling Untrusted File Formats Safely, that's what WUFFS is. So it's not about an "isolated process" it's about a choice to do shoddy engineering and a society which has decided that shoddy engineering is fine in this particular domain.
This is totally on-brand for Apple.
"Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS."
That's an RCE, but nowhere near as bad as other recent exploits (CVE-2023-41064 and CVE-2023-41061) that include device and account takeover from an iMessage that you don't have to read. Also these typically don't rate highest severity (7.5/High) probably due to the limited scope of the targets.
It's not really esoteric given it's part of Apple's push into Spatial Audio as early as 2020 (movies in 2020, Apple Music in 2021). Sure you might have no intention of listening to this, but it's wrong to say it's esoteric given the amount of marketing material Apple has put out.
> attack against specific targeted individuals on iOS
I'm sure Pegasus will come up with another exploit to replace this one.
[flagged]
[flagged]
[flagged]
[flagged]
So, what if it's a bug in a project that has forked a few times with renames? You're possibly inviting people to ignore a CVE that says "chrome" or "webkit" or "blink" in the name, when in reality it could be from far enough in the past that it affects all of them.
What about project with a license that allows for easy inclusion of source in another project (BSD license, for example). If most people are exposed to the bug through a bunch of other projects that include it, what do you name it? Any choice likely implies something that might keep people from looking closer initially when they are affected.
What about this specific but? Should it say CoreAudio, or iOS, MacOS, or just Apple?
Naming things usefully in a way that conveys additional information is hard. Looking up CVEs is fairly easy. Just throw it into a search engine.
You have it backwards: I can't remember to care about CVE 2025 31200 vs CVE 2025 32100. People should refer to CoreAudio Corruption Antelope and the infrastructure should allow em to easily search for that and get it unambiguosly linked to CVE 2025 31200 (or was it 32100? Better double-check.)
You can remember CoreAudio Corruption Antelope a lot longer than you can care about 2025 301200.
As for whether it's CoreAudio or IOS or Apple or whatever: as long as it is not woefully inaccurate, it's fine. The format is necessary to prevent people from marketing "Extreme Apocalypso" as the name for an input issue in syslog that can only be used to fill a disk slowly.
a CVE is just a link to uniquely identify a specific problem. They often also have names, coined by the people that discovered them, such as "heartbleed". A CVE is similar in concept than a URL shortener but with more procedural name generation.
A CVE is not the actual exploit or security issue, it's a way to reference the exploit or security issue. Internally, before this got a CVE entry, it likely also had an entry in Apple's internal bug system tracking. The identifier for that is similarly just another way to reference this specific problem.
A CVE number is no different than an incrementing ID in a database, except that it encodes slightly more information in the name. You can try to put additional information in the identifier, but it's hard to change after the fact, so you want to be careful what you put. Should you put the score in the identifier? Careful, they often increase after additional scrutiny is given to the issue. What about the product name, as is requested here? Sometimes additional products are discovered that are affected later. Sometimes those are just as important or more as the original, but the correct people that knew weren't contacted until the CVE was released. A CVE is most useful in providing a global id that different parties can use to reference the same item in their own databases.
It's an identifier. Keep it simple. Call it whatever you want in addition to that. If you subscribe to the CISA catalog update mailing list, they reference items like so, which is perfectly fine IMO:
- CVE-2025-4632 Samsung MagicINFO 9 Server Path Traversal Vulnerability
But that's not the CVE itself that is noting what it affects, that is CISA proving a summary of the problem, and notably in this case, one that's more descriptive than listed on the item itself and a combination of a few fields.
Edit: I'll note that from looking at a different response to me, that if you were just suggesting people name stuff more usefully when submitting here, I have absolutely zero problems with that suggestion, which should be obvious by the above. I interpreted your original comment to mean "CVE's should have more context in their names", which is what I disagree with if we're talking about the name as identifier.
Think DNS vs IP.
"Hey, Kentrak! I'm concerned about 2600:1401:d000:38a::1aca."
versus
"Hey, Kentrak! I'm concerned about the Akamai node that's answering for www.apple.com!"
If you are staring at the same one for hours upon hours, you might remember the number. I'm saying that any time someone is referencing a CVE in any other context, they should use a memorable, informative, searchable, non-clickbaity name.
Previously I have expressed negative feelings about people claiming Heartbleed, Shellshock, and so forth -- they are unnecessarily dramatic. Now I feel that we need a middle course.
CVEs are always filed against a specific product. If it's in a library, then it's typically the library and not all of its user. All of that information is already in the CVE database: https://nvd.nist.gov/vuln/detail/CVE-2025-31200
What OP wanted to stress is that just the CVE number on its own is not very helpful as a title. It would be helpful to at least mention the type of vulnerability and the affected product according to the CVE database entry.
Possibly, in which case, I'm not in disagreement, but that's not how I interpreted "Okay, fine: there is a use for human names for security bugs".
I'm happy to be wrong about this, but it strikes me that the fallacy of this argument is that it says that some bugs would be ignored because of namung confusion. But that's already the status quo for all bugs!
I have a secondary reservation which is that people don't really browse for bugs by name in the way that this argument suggests.
Also, both of them could be solved just by replacing Antelope with a serial number.
> the fallacy of this argument is that it says that some bugs would be ignored because of namung confusion. But that's already the status quo for all bugs!
I don't think so. The difference is when you arbitrarily constrain data your introduce errors and edge cases. Either the name is standardized in which case what can go in portions of it needs to be constrained, or it's not. If it's constrained, someone will need to make a decision on what's appropriate and inappropriate to add. If the list of items that can and should be put in that field is large, you're likely so see some or (most) omitted.
The real question is whether that omission will be viewed as people to imply something is unaffected before they look more closely, and then ignore what might be something important. An argument could also be made that people might see a CVE name without a product and decide that it doesn't affect them, or ignore it when they might have looked closer because something in the name caught their attention, but I think that's a slightly different problem. I think my stance can mostly be boiled down to not wanting to unintentionally train people to rely on something that is unreliable.
I'll freely admit there are cases for both sides of this and differing opinions. It's similar to Postel's law in that it deals to a degree with human nature and people's propensity to take shortcuts (in both actions and thinking), so what we're actually talking about is how we perceive human nature and how it interacts with systems we create.
Software bill of materials type of initiatives could help with that.
[flagged]
Bug names are useful for bugs the average sysadmin needs to know about and talk about, e.g. heartbleed, spectre. This bug feels more like an update and forget it type of bug. I don't think it needs a unique name.
We could name them like hurricanes.
Kind of hard to come up with tens of thousands of huricane names.
Maybe we should write less software.
[flagged]
I'm with you; I get ocular migraines from dark mode.
+1 for your first comment!
> Essentially, if you have a vector, say [A,B,C] that you actually want to be [B,A,C], then you might do that with a ‘permutation map’: another vector that says where each element should go. In this case that would be [1,0,2], which means that the element at index 1 should go to index 0, and the element at index 0 should go to index 1 and the element at index 2 should stay where it is. The simplest working way to do this is to just allocate another vector, and essentially use the permutation map as a kind of dictionary (index→element) for populating that third vector. However, if you would rather be clever and don’t feel like allocating a whole other vector, then you can use the algorithm above.
This isn't being clever, it's actually incorrect to allocate a whole other vector. Realtime code requires O(1) memory complexity for correctness. Although the smart thing would be to preallocate a buffer for the pointers, but in general that may not be possible (I'm not an expert in CoreAudio but if the channels are interleaved and the next chunk of code expects to process in place you really do have to it this way).
It sounds like the CVE is super simple, reduced to:
- CoreAudio determines the number of channels before playback to create a resource, standard practice in audio processing
- It then trusts the number of channels of an incoming stream when using that resource
- A maliciously crafted audio file can bypass checks for this and trigger a buffer overflow
Never trust your inputs, folks.
The reason this comes up with HOA to me is not surprising: almost no one uses HOA, and a variety of other optimizations like assuming the "H" in HOA only refers to up to 128 channels (since afaik, no one even tries past that point).
> Imagine if the primitive is that you can write n 8 byte sequences out of bounds, but they must be valid 32 bit floats in the range x-y
I imagine the only thing you need to guarantee is you don't use subnormals, since audio code usually enables FTZ mode on both ARM and x86.
> This isn't being clever, it's actually incorrect to allocate a whole other vector. Realtime code requires O(1) memory complexity for correctness.
You can just allocate the scratch buffer beforehand.