[HN Gopher] CVE 2025 31200
___________________________________________________________________
CVE 2025 31200
Author : todsacerdoti
Score : 79 points
Date : 2025-06-02 18:58 UTC (4 hours ago)
(HTM) web link (blog.noahhw.dev)
(TXT) w3m dump (blog.noahhw.dev)
| dsr_ wrote:
| Okay, fine: there _is_ a use for human names for security bugs.
|
| Gosh, this CVE was allocated in 2025. That's useful.
|
| I hereby propose the Non-Clickbait Naming Convention in Three
| Parts:
|
| - the affected system(s)
|
| - the general kind of problem
|
| - a noun not used before with part 2
|
| So this can be the CoreAudio Corruption Antelope.
| kbenson wrote:
| 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.
| speerer wrote:
| 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.
| kbenson wrote:
| > 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.
| TonyTrapp wrote:
| 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.
| kbenson wrote:
| 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".
| Tarq0n wrote:
| Software bill of materials type of initiatives could help
| with that.
| dsr_ wrote:
| 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.
| kbenson wrote:
| 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.
| dsr_ wrote:
| 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.
| edflsafoiewq wrote:
| We could name them like hurricanes.
| bawolff wrote:
| Kind of hard to come up with tens of thousands of huricane
| names.
| myself248 wrote:
| Maybe we should write less software.
| bawolff wrote:
| 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.
| duped wrote:
| > 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.
| saghm wrote:
| 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];
| }
|
| I'm not sure what that loop is supposed to be doing, but as its
| written it looks like it would either be skipped entirely or
| never terminate; after single iteration, the the two values would
| be equal and never change again.
| johnfn wrote:
| The authors probably intended to write:
| index = remapVec[index];
|
| which would do a better job at following a cycle.
| ec109685 wrote:
| 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?
| Hilift wrote:
| 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.
|
| https://www.tenable.com/cve/CVE-2025-31200
| ChocolateGod wrote:
| > attack against specific targeted individuals on iOS
|
| I'm sure Pegasus will come up with another exploit to replace
| this one.
___________________________________________________________________
(page generated 2025-06-02 23:00 UTC)