Categories: Business
Tags: Janet Jackson

Tags:  music

Tags:  rhythm nation

Tags:  song

Tags:  video

Tags:  resonant frequency

Tags:  hard drive

We take a look at news of the Janet Jackson smash Rhythm Nation causing bizarre issues for certain older hard drive models.



(Read more...)




The post Bad rhythm: Janet Jackson song resonates poorly with some old hard drives appeared first on Malwarebytes Labs.

Janet Jackson’s Rhythm Nation music video would have caused quite the commotion back in the old Windows XP days. If you’re still running a certain model of an OEM hard drive from the Windows XP days, you may still be liable to experience the same thing today. However, said commotion was not solely down to the choreography or phenomenal beats.

Rythym Nation by Janet Jackson came with a peculiar quirk. That quirk involved crashing the hopes and dreams of the person watching it, along with their hard drive.

Microsoft writer Raymond Chen reveals the somewhat bizarre tale of Janet’s computer stomping abilities in a recent blog post.

**What was happening here?**

Back in the olden times, it turns out that specific flavours of hardware running Windows XP did not like Janet busting a move. Some different models of laptop, from competitors of the first brand, would also crash. Even more spectacularly: simply playing the song on one device could make a second device nearby crash.

Old style mechanical hard drives are slowly being replaced by SSD drives. You may find them being used by gamers for cheap and easy excess game storage, but the mechanical hard drive’s time in the sun is over.

Mechanical drives have a whole lot of vibration going on inside, and this is where the drives become vulnerable to very peculiar forms of frequency based risk. Indeed, using the resonant frequency of the drive itself to make it stop working properly is not a new concept. Low frequency noise was used in tests during 2018 to break CCTV and prevent a laptop’s operating system from working.

**Dancefloor devastation for your hard drive**

Janet, ever the innovator, was clearly one step ahead of security researchers. By chance, it turns out that Rhythm Nation matched a resonant frequency for the hard drive used in these particular types of laptop.If you run into a mechanical drive in a device these days, there’s a good chance it’ll be a 7,200 RPM drive (RPM is the number of revolutions the drive’s platter makes per minute). The drives struck here, smooth criminal style,were specific models clocking in at 5,400RPM.

Custom filters were added by manufacturers in the audio pipeline. These filters swung into action at the first sign of a Rhythm Nation intro and removed the frequencies as the audio played.

**A CVE: better late than never**

This rhythm-based tale of woe seemingly has no end. The Register noticed an entry on the list of Common Vulnerabilities and Exposures (CVEs), listed as CVE-2022-38392. From the description, surely Janet’s finest hour:

_A certain 5400 RPM OEM hard drive, as shipped with laptop PCs in approximately 2005, allows physically proximate attackers to cause a denial of service (device malfunction and system crash) via a resonant-frequency attack with the audio signal from the Rhythm Nation music video._

From further down the page, a rather relevant warning:

_Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE._

As I close the lid on my 2005 Windows XP laptop for the last time, never a truer word was spoken.

Bad rhythm: Janet Jackson song resonates poorly with some old hard drives

An issue in AP4_SgpdAtom::AP4_SgpdAtom() of Bento4-1.6.0-639 allows attackers to cause a Denial of Service (DoS) via a crafted mp4 input.

**Vulnerability description**

**version:** Bento4-1.6.0-639  
**command:** ./mp42aac $POC /dev/null  
**Download:** poc

Here is the trace reported by ASAN:

    $ mp42aac poc /dev/null
    
    AddressSanitizer: Out of memory. The process has exhausted 65536MB for size class 48.
    =================================================================
    ==29843==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0x18 bytes
        #0 0x7ffff769b947 in operator new(unsigned long) (/lib/x86_64-linux-gnu/libasan.so.5+0x10f947)
        #1 0x555555911f52 in AP4_List<AP4_DataBuffer>::Add(AP4_DataBuffer*) /path_to_Bento4/Source/C++/Core/Ap4List.h:160
        #2 0x5555559114bd in AP4_SgpdAtom::AP4_SgpdAtom(unsigned int, unsigned char, unsigned int, AP4_ByteStream&) /path_to_Bento4/Source/C++/Core/Ap4SgpdAtom.cpp:111
        #3 0x555555910da4 in AP4_SgpdAtom::Create(unsigned int, AP4_ByteStream&) /path_to_Bento4/Source/C++/Core/Ap4SgpdAtom.cpp:54
        #4 0x55555589399c in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:729
        #5 0x555555890224 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:233
        #6 0x5555558b9c5f in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194
        #7 0x5555558b96c2 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139
        #8 0x5555558b9229 in AP4_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88
        #9 0x555555893d26 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:796
        #10 0x555555890224 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:233
        #11 0x5555558c7b47 in AP4_DrefAtom::AP4_DrefAtom(unsigned int, unsigned char, unsigned int, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4DrefAtom.cpp:84
        #12 0x5555558c768b in AP4_DrefAtom::Create(unsigned int, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4DrefAtom.cpp:50
        #13 0x555555892ccd in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:560
        #14 0x555555890224 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:233
        #15 0x5555558b9c5f in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194
        #16 0x5555558b96c2 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139
        #17 0x5555558b9229 in AP4_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88
        #18 0x555555893d26 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:796
        #19 0x555555890224 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:233
        #20 0x5555558b9c5f in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194
        #21 0x5555558b96c2 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139
        #22 0x5555558b9229 in AP4_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88
        #23 0x555555893d26 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:796
        #24 0x555555890224 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:233
        #25 0x5555558b9c5f in AP4_ContainerAtom::ReadChildren(AP4_AtomFactory&, AP4_ByteStream&, unsigned long long) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:194
        #26 0x5555558b96c2 in AP4_ContainerAtom::AP4_ContainerAtom(unsigned int, unsigned long long, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:139
        #27 0x5555558b9229 in AP4_ContainerAtom::Create(unsigned int, unsigned long long, bool, bool, AP4_ByteStream&, AP4_AtomFactory&) /path_to_Bento4/Source/C++/Core/Ap4ContainerAtom.cpp:88
        #28 0x555555893d26 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned int, unsigned int, unsigned long long, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:796
        #29 0x555555890224 in AP4_AtomFactory::CreateAtomFromStream(AP4_ByteStream&, unsigned long long&, AP4_Atom*&) /path_to_Bento4/Source/C++/Core/Ap4AtomFactory.cpp:233
    
    ==29843==HINT: if you don't care about these errors you may set allocator_may_return_null=1
    SUMMARY: AddressSanitizer: out-of-memory (/lib/x86_64-linux-gnu/libasan.so.5+0x10f947) in operator new(unsigned long)
    ==29843==ABORTING
    

**Vulnerability analysis**

AP4\_UI32 entry\_count = 0;

AP4\_Result result = stream.ReadUI32(entry\_count);

if (AP4\_FAILED(result)) return;

bytes\_available -= 4;

// read all entries

for (unsigned int i=0; i<entry\_count; i++) {

AP4\_UI32 description\_length = m\_DefaultLength;

if (m\_Version == 0) {

// entry size unknown, read the whole thing

description\_length = bytes\_available;

} else {

if (m\_DefaultLength == 0) {

description\_length = stream.ReadUI32(description\_length);

}

}

if (description\_length <= bytes\_available) {

AP4\_DataBuffer\* payload = new AP4\_DataBuffer();

if (description\_length) {

payload->SetDataSize(description\_length);

stream.Read(payload->UseData(), description\_length);

}

m\_Entries.Add(payload);

}

}

}

    pwndbg> p entry_count
    $1 = 4278190081
    pwndbg> p m_DefaultLength
    $2 = 20
    pwndbg> p m_Version
    $3 = 1 '\001'
    pwndbg> p bytes_available
    $4 = 20
    

The possible cause of this issue is that a crafted input can set entry_count to a large value (4,278,190,081) in line 90. Such a long loop (line 95-114) will allocate a lot of memory in line 106 and line 111, which eventually exhausts the memory. Since the return value of stream.Read is not checked in line 109, the loop will not terminate at the end of the input file.

CVE-2022-35165: Possible memory exhuastion in AP4_SgpdAtom::AP4_SgpdAtom(). The process has exhausted 65536MB memory. · Issue #712 · axiomatic-systems/Bento4

An infinite loop flaw was found in the USB xHCI controller emulation of QEMU while computing the length of the Transfer Request Block (TRB) Ring. This flaw allows a privileged guest user to hang the QEMU process on the host, resulting in a denial of service.

'1908004?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2020-14394: Invalid Bug ID

A crafted HTTP packet without a content-type header can create a denial-of-service condition in Softing Secure Integration Server V1.22.

CVE-2022-2547

A certain 5400 RPM OEM hard drive, as shipped with laptop PCs in approximately 2005, allows physically proximate attackers to cause a denial of service (device malfunction and system crash) via a resonant-frequency attack with the audio signal from the Rhythm Nation music video.

August 16th, 2022

A colleague of mine shared a story from Windows XP product support. A major computer manufacturer discovered that playing the music video for Janet Jackson’s “Rhythm Nation” would crash certain models of laptops. I would not have wanted to be in the laboratory that they must have set up to investigate this problem. Not an artistic judgement.

One discovery during the investigation is that playing the music video also crashed some of their competitors’ laptops.

And then they discovered something extremely weird: Playing the music video on one laptop caused a laptop sitting nearby to crash, even though that other laptop wasn’t playing the video!

What’s going on?

It turns out that the song contained one of the natural resonant frequencies for the model of 5400 rpm laptop hard drives that they and other manufacturers used.

The manufacturer worked around the problem by adding a custom filter in the audio pipeline that detected and removed the offending frequencies during audio playback.

And I’m sure they put a digital version of a “Do not remove” sticker on that audio filter. (Though I’m worried that in the many years since the workaround was added, nobody remembers why it’s there. Hopefully, their laptops are not still carrying this audio filter to protect against damage to a model of hard drive they are no longer using.)

And of course, no story about natural resonant frequencies can pass without a reference to the collapse of the Tacoma Narrows Bridge in 1940.

**Related**: Shouting in the Datacenter.

**Bonus chatter**: Video version of this story and a Twitter poll.

Also, Larry Osterman had a similar experience with a specific game that crashed a prototype PC.

CVE-2022-38392: Janet Jackson had the power to crash laptop computers

A Null Pointer dereference vulnerability exists in GPAC 2.1-DEV-revUNKNOWN-master via the function gf_filter_pid_set_property_full () at filter_core/filter_pid.c:5250,which causes a Denial of Service (DoS). This vulnerability was fixed in commit b43f9d1.

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

*   I looked for a similar issue and couldn't find any.
*   I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop\_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: http://gpac.io/2013/07/16/how-to-file-a-bug-properly/

**Description:**  
\`A crash happened on MP4Box(GPAC version 2.1-DEV-revUNKNOWN-master) due to a null pointer dereference vulnerability in gf\_filter\_pid\_set\_property\_full function (filter\_core/filter\_pid.c:5250) .

\`  
**MP4Box version**

    ./MP4Box -version
    MP4Box - GPAC version 2.1-DEV-revUNKNOWN-master
    (c) 2000-2022 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io
    
    Please cite our work in your research:
    	GPAC Filters: https://doi.org/10.1145/3339825.3394929
    	GPAC: https://doi.org/10.1145/1291233.1291452
    
    GPAC Configuration: --enable-sanitizer
    Features: GPAC_CONFIG_LINUX GPAC_64_BITS GPAC_HAS_IPV6 GPAC_HAS_SSL GPAC_HAS_SOCK_UN GPAC_MINIMAL_ODF GPAC_HAS_QJS GPAC_HAS_LINUX_DVB  GPAC_DISABLE_3D 
    

**poc**  
poc.zip

**command**  
./MP4Box -info poc

**crash output**

    [AVC|H264] Warning: Error parsing NAL unit
    filter_core/filter_pid.c:5250:6: runtime error: member access within null pointer of type 'struct GF_FilterPid'
    

**gdb output**

    pwndbg> r
    Starting program: /home/fuzz/gpac2.1/gpac/bin/gcc/MP4Box -info ../../../test/segv2/poc
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    [AVC|H264] Warning: Error parsing NAL unit
    filter_core/filter_pid.c:5250:6: runtime error: member access within null pointer of type 'struct GF_FilterPid'
    [Inferior 1 (process 2239153) exited with code 01]
    pwndbg> b filter_pid.c:5250
    Breakpoint 1 at 0x7ffff4b829f6: filter_pid.c:5250. (6 locations)
    pwndbg> r
    Starting program: /home/fuzz/gpac2.1/gpac/bin/gcc/MP4Box -info ../../../test/segv2/poc
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    
    Breakpoint 1, gf_filter_pid_set_property_full (is_info=GF_FALSE, value=0x7ffffffe9150, dyn_name=0x0, prop_name=0x0, prop_4cc=1347244884, pid=0x613000000040) at filter_core/filter_pid.c:5301
    5301		return gf_filter_pid_set_property_full(pid, prop_4cc, NULL, NULL, value, GF_FALSE);
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ REGISTERS ]─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
     RAX  0x0
     RBX  0x7ffffffe8f50 ◂— 0x41b58ab3
     RCX  0xfffffffd22a ◂— 0x0
     RDX  0x7ffffffe9150 ◂— 0x2
     RDI  0x613000000040 ◂— 0x613000000040 /* '@' */
     RSI  0x504d5354
     R8   0x0
     R9   0x7ffff58cb4f0 (global_log_tools+496) ◂— 0x2
     R10  0x7ffff24ab3f1 ◂— 'gf_filter_pid_set_property'
     R11  0x7ffff4b84110 (gf_filter_pid_set_property) ◂— endbr64 
     R12  0x613000000040 ◂— 0x613000000040 /* '@' */
     R13  0x7ffffffe9150 ◂— 0x2
     R14  0x504d5354
     R15  0xfffffffd1ea ◂— 0x0
     RBP  0x7ffffffe9060 —▸ 0x7ffffffe9380 —▸ 0x7ffffffea0d0 —▸ 0x7ffffffea170 —▸ 0x7ffffffea280 ◂— ...
     RSP  0x7ffffffe8f30 ◂— 0x0
     RIP  0x7ffff4b841c6 (gf_filter_pid_set_property+182) ◂— test   r12, r12
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ DISASM ]──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
     ► 0x7ffff4b841c6 <gf_filter_pid_set_property+182>    test   r12, r12
       0x7ffff4b841c9 <gf_filter_pid_set_property+185>    je     gf_filter_pid_set_property+1477                <gf_filter_pid_set_property+1477>
     
       0x7ffff4b841cf <gf_filter_pid_set_property+191>    test   r12b, 7
       0x7ffff4b841d3 <gf_filter_pid_set_property+195>    jne    gf_filter_pid_set_property+1477                <gf_filter_pid_set_property+1477>
     
       0x7ffff4b841d9 <gf_filter_pid_set_property+201>    mov    rax, r12
       0x7ffff4b841dc <gf_filter_pid_set_property+204>    shr    rax, 3
       0x7ffff4b841e0 <gf_filter_pid_set_property+208>    cmp    byte ptr [rax + 0x7fff8000], 0
       0x7ffff4b841e7 <gf_filter_pid_set_property+215>    jne    gf_filter_pid_set_property+1447                <gf_filter_pid_set_property+1447>
     
       0x7ffff4b841ed <gf_filter_pid_set_property+221>    cmp    r12, qword ptr [r12]
       0x7ffff4b841f1 <gf_filter_pid_set_property+225>    jne    gf_filter_pid_set_property+1016                <gf_filter_pid_set_property+1016>
     
       0x7ffff4b841f7 <gf_filter_pid_set_property+231>    mov    esi, r14d
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ SOURCE (CODE) ]───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    In file: /home/fuzz/gpac2.1/gpac/src/filter_core/filter_pid.c
       5296 
       5297 GF_EXPORT
       5298 GF_Err gf_filter_pid_set_property(GF_FilterPid *pid, u32 prop_4cc, const GF_PropertyValue *value)
       5299 {
       5300 	if (!prop_4cc) return GF_BAD_PARAM;
     ► 5301 	return gf_filter_pid_set_property_full(pid, prop_4cc, NULL, NULL, value, GF_FALSE);
       5302 }
       5303 
       5304 GF_EXPORT
       5305 GF_Err gf_filter_pid_set_property_str(GF_FilterPid *pid, const char *name, const GF_PropertyValue *value)
       5306 {
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ STACK ]───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    00:0000│ rsp 0x7ffffffe8f30 ◂— 0x0
    01:0008│     0x7ffffffe8f38 ◂— 0x0
    02:0010│     0x7ffffffe8f40 —▸ 0x7ffffffe9030 —▸ 0x7ffff54af2c0 ◂— 0x6372636170672e /* '.gpacrc' */
    03:0018│     0x7ffffffe8f48 —▸ 0x7ffffffe8f50 ◂— 0x41b58ab3
    04:0020│ rbx 0x7ffffffe8f50 ◂— 0x41b58ab3
    05:0028│     0x7ffffffe8f58 —▸ 0x7ffff5640eff ◂— '1 48 100 11 szName:5290'
    06:0030│     0x7ffffffe8f60 —▸ 0x7ffff4b84110 (gf_filter_pid_set_property) ◂— endbr64 
    07:0038│     0x7ffffffe8f68 —▸ 0x618000000c80 —▸ 0x7ffff6de03e0 (FileInRegister) —▸ 0x7ffff56a6580 ◂— 0x6e6966 /* 'fin' */
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ BACKTRACE ]─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
     ► f 0   0x7ffff4b841c6 gf_filter_pid_set_property+182
       f 1   0x7ffff4b841c6 gf_filter_pid_set_property+182
       f 2   0x7ffff4c06993 gf_filter_pid_raw_new+595
       f 3   0x7ffff4dc30b1 filein_process+2721
       f 4   0x7ffff4c0eb6d gf_filter_process_task+3581
       f 5   0x7ffff4bd4953 gf_fs_thread_proc+2275
       f 6   0x7ffff4be0c67 gf_fs_run+455
       f 7   0x7ffff462a677 gf_media_import+10263
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    pwndbg> bt
    #0  gf_filter_pid_set_property_full (is_info=GF_FALSE, value=0x7ffffffe9150, dyn_name=0x0, prop_name=0x0, prop_4cc=1347244884, pid=0x613000000040) at filter_core/filter_pid.c:5301
    #1  gf_filter_pid_set_property (pid=pid@entry=0x613000000040, prop_4cc=prop_4cc@entry=1347244884, value=0x7ffffffe9150) at filter_core/filter_pid.c:5301
    #2  0x00007ffff4c06993 in gf_filter_pid_raw_new (filter=filter@entry=0x618000000c80, url=0x603000000f40 "../../../test/segv2/poc", local_file=<optimized out>, mime_type=<optimized out>, fext=<optimized out>, probe_data=<optimized out>, probe_size=<optimized out>, trust_mime=<optimized out>, out_pid=<optimized out>) at filter_core/filter.c:3891
    #3  0x00007ffff4dc30b1 in filein_process (filter=<optimized out>) at filters/in_file.c:481
    #4  0x00007ffff4c0eb6d in gf_filter_process_task (task=0x607000000b10) at filter_core/filter.c:2639
    #5  0x00007ffff4bd4953 in gf_fs_thread_proc (sess_thread=sess_thread@entry=0x616000000110) at filter_core/filter_session.c:1857
    #6  0x00007ffff4be0c67 in gf_fs_run (fsess=fsess@entry=0x616000000080) at filter_core/filter_session.c:2118
    #7  0x00007ffff462a677 in gf_media_import (importer=importer@entry=0x7ffffffeaa50) at media_tools/media_import.c:1226
    #8  0x0000555555651a12 in convert_file_info (inName=<optimized out>, track_id=0x555555764fb0 <info_track_id>) at fileimport.c:130
    #9  0x000055555562279f in mp4box_main (argc=<optimized out>, argv=<optimized out>) at mp4box.c:6265
    #10 0x00007ffff1949083 in __libc_start_main (main=0x5555555f6a00 <main>, argc=3, argv=0x7fffffffe488, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe478) at ../csu/libc-start.c:308
    #11 0x00005555555f6afe in _start () at mp4box.c:6811
    pwndbg> p pid
    $2 = (GF_FilterPid *) 0x613000000040
    pwndbg> c
    Continuing.
    [AVC|H264] Warning: Error parsing NAL unit
    
    Breakpoint 1, gf_filter_pid_set_property_full (is_info=GF_FALSE, value=0x7ffffffe9810, dyn_name=0x0, prop_name=0x0, prop_4cc=1146050121, pid=0x0) at filter_core/filter_pid.c:5301
    5301		return gf_filter_pid_set_property_full(pid, prop_4cc, NULL, NULL, value, GF_FALSE);
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    ............
    until.......
    
    pwndbg> p pid
    $3 = (GF_FilterPid *) 0x0
    pwndbg> i b
    Num     Type           Disp Enb Address            What
    1       breakpoint     keep y   <MULTIPLE>         
    	breakpoint already hit 9 times
    1.1                         y   0x00007ffff4b829f6 in gf_filter_pid_set_property_full at filter_core/filter_pid.c:5250
    1.2                         y   0x00007ffff4b8314e in gf_filter_pid_set_property_full at filter_core/filter_pid.c:5250
    1.3                         y   0x00007ffff4b834d1 in gf_filter_pid_set_property_full at filter_core/filter_pid.c:5250
    1.4                         y   0x00007ffff4b8393e in gf_filter_pid_set_property_full at filter_core/filter_pid.c:5250
    1.5                         y   0x00007ffff4b83cc1 in gf_filter_pid_set_property_full at filter_core/filter_pid.c:5250
    1.6                         y   0x00007ffff4b841c6 in gf_filter_pid_set_property_full at filter_core/filter_pid.c:5250
    pwndbg> n
    filter_core/filter_pid.c:5250:6: runtime error: member access within null pointer of type 'struct GF_FilterPid'
    [Inferior 1 (process 2239158) exited with code 01]
    
    

**source code**

    5246 static GF_Err gf_filter_pid_set_property_full(GF_FilterPid *pid, u32 prop_4cc, const char *prop_name, char *dyn_name, const GF_PropertyValue *value, Bool is_info)
    5247 {
    5248 	GF_PropertyMap *map;
    5249 	const GF_PropertyValue *oldp;
    5250	if (PID_IS_INPUT(pid)) {    //**here**//
    5251		GF_LOG(GF_LOG_ERROR, GF_LOG_FILTER, ("Attempt to write property on input PID in filter %s - ignoring\n", pid->filter->name));
    5252		return GF_BAD_PARAM;
    5253	}

CVE-2022-36186: A NULL pointer dereference in gf_filter_pid_set_property_full  · Issue #2223 · gpac/gpac

In Moodle before 3.9.1, 3.8.4, 3.7.7 and 3.5.13, yui_combo needed to limit the amount of files it can load to help mitigate the risk of denial of service.

CVE-2020-14322

A flaw was found in Red Hat AMQ Broker in a way that a XEE attack can be done via Broker's configuration files, leading to denial of service and information disclosure.

'1840862?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2020-14379: Invalid Bug ID

This advisory contains mitigations for a Denial of Service vulnerability in CENTUM Controller FCS products.

Yokogawa CENTUM Controller FCS

Mobile transactions could’ve been disabled, created and signed by attackers.

Mobile transactions could’ve been disabled, created and signed by attackers.

Smartphone maker Xiaomi, the world’s number three phone maker behind Apple and Samsung, reported it has patched a high-severity flaw in its “trusted environment” used to store payment data that opened some of its handsets to attack.

Researchers at Check Point Research revealed last week in a report released at DEF CON that the Xiaomi smartphone flaw could have allowed hackers to hijack the mobile payment system and disable it or create and sign their own forged transactions.

The potential pool of victims was massive, considering one in seven of the world’s smartphones are manufactured by Xiaomi, according to Q2/22 data from Canalys. The company is the third largest vendor globally, according to Canalys.  
“We discovered a set of vulnerabilities that could allow forging of payment packages or disabling the payment system directly, from an unprivileged Android application. We were able to hack into WeChat Pay and implemented a fully worked proof of concept,” wrote Slava Makkaveev, security researcher with Check Point.

He said, the Check Point study marks the first time Xiaomi’s trusted applications have been reviewed for security issues. WeChat Pay is a mobile payment and digital wallet service developed by a firm of the same name, which is based in China. The service is used by over 300 million customers and allows Android users to make mobile payments and online transactions.

**The Flaw**

It’s unclear how long the vulnerability existed or if it was exploited by attackers in the wild. The bug, tracked as CVE-2020-14125, was patched by Xiaomi in June and has a CVSS severity rating of high.

“A denial of service vulnerability exists in some Xiaomi models of phones. The vulnerability is caused by out-of-bound read/write and can be exploited by attackers to make denial of service,” according to the NIST common vulnerability and exposure description of the bug.

While details of the bug’s impact were limited at the time Xiaomi disclosed the vulnerability in June, researchers at Check Point have outlined in its postmortem of the patched bug and the full potential impact of the flaw.

The core issue with Xiaomi phone was the mobile phones payment method and the Trusted Execution Environment (TEE) component of the phone. The TEE is the Xiaomi’s virtual enclave of the phone, responsible for processing and storing ultra-sensitive security information such fingerprints and the cryptographic keys used in signing transactions.

“Left unpatched, an attacker could steal private keys used to sign WeChat Pay control and payment packages. Worst case, an unprivileged Android app could have created and signed a fake payment package,” researchers wrote.

Two types of attacks could have been performed against handsets with the flaw according to Check Point.

*   From an unprivileged Android app: The user installs a malicious application and launches it. The app extracts the keys and sends a fake payment packet to steal the money.
*   If the attacker has the target devices in their hands: The attacker rootes the device, then downgrades the trust environment, and then runs the code to create a fake payment package without an application.

**Two Ways to Skin a TEE**

Controlling the TEE, according to Check Point, is a MediaTek chip component that needed to be present to conduct the attack. To be clear, the flaw was not in the MediaTek chip – however the bug was only executable in phones configured with the MediaTek processor.

“The Asian market,” the researchers noted, is “mainly represented by smartphones based on MediaTek chips.” Xiaomi phones that run on MediaTek chips use a TEE architecture called “Kinibi,” within which Xiaomi can embed and sign their own trusted applications.

“Usually, trusted apps of the Kinibi OS have the MCLF format” – Mobicore Loadable Format – “but Xiaomi decided to come up with one of their own.” Within their own format, however, was a flaw: an absence of version control, without which “an attacker can transfer an old version of a trusted app to the device and use it to overwrite the new app file.” The signature between versions doesn’t change, so the TEE doesn’t know the difference, and it loads the old one.

In essence the attacker could’ve turned back time, bypassing any security fixes made by Xiaomi or MediaTek in the most sensitive area of the phone.

As a case-in-point, the researchers targeted “Tencent soter,” Xiaomi’s embedded framework providing an API to third-party apps that want to integrate mobile payments. Soter is what’s responsible for verifying payments between phones and backend servers, for hundreds of millions of Android devices worldwide. The researchers performed time travel to exploit an arbitrary read vulnerability in the soter app. This allowed them to steal the private keys used to sign transactions.

The arbitrary read vulnerability is already patched, while the version control vulnerability is “being fixed.”

In addition, the researchers came up with one other trick for exploiting soter.

Using a regular, unprivileged Android application, they were able to communicate with the trusted soter app via “SoterService,” an API for managing soter keys. “In practice, our goal is to steal one of the soter private keys,” the authors wrote. However, by performing a classic heap overflow attack, they were able to “completely compromise the Tencent soter platform,” allowing much greater power to, for example, sign fake payment packages.

**Phones Remain Un-scrutinized**

Mobile payments are already receiving more scrutiny from security researchers, as services like Apple Pay and Google Pay gain popularity in the West. But the issue is even more significant for the Far East, where the market for mobile payments is already way ahead. According to data from Statista, that hemisphere was responsible for a full two-thirds of mobile payments globally in 2021 – about four billion dollars in transactions in all.

And yet, the Asian market “has still not yet been widely explored,” the researchers noted. “No one is scrutinizing trusted applications written by device vendors, such as Xiaomi, instead of by chip manufacturers, even though security management and the core of mobile payments are implemented there.”

As previously noted, Check Point asserted this was the first time Xiaomi’s trusted applications have been reviewed for security issues.

Tag

#dos