[old] public security bugs go unresolved since 2015

Undescribed Horrific Abuse, One Victim & Survivor of Many gmkarl at gmail.com
Tue May 2 15:41:58 PDT 2023


stumbled on this while engaging similar symptoms; clang and ios,
example for within “a-shell” app. sounds like there may likely be a
lot more across ecosystems from where this came from.

https://github.com/holzschu/a-shell/issues/306

a-Shell 180 (1.7.4) | iPad8,12 | iPhone OS 14.7.1 (18G82) | Crash |
PoC | EXC_BAD_ACCESS (SIGSEGV)

> Hello-
>
> Crasher PoC: printf 'k80x&::((**\ne::' | clang -x c++ -
>
> Hardware Model: iPad8,12 OS Version: iPhone OS 14.7.1 (18G82)
>
> Run Twice, See Seg Fault 11
>
> A few comments:
>
> 1. There is no printf obviously
> 2. The PoC needs to be run twice to SegFault 11
>
> Hopefully this is enough info to be able to reproduce the Crash.
>
> If I should Report this Issue elsewhere, please let me know.
>
> Thank You
>
> ```
> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
> Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000030
> VM Region Info: 0x30 is not in any region.  Bytes before following region: 4310319056
>       REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
>       UNUSED SPACE AT START
> --->
>       __TEXT                   100ea4000-100eb4000 [   64K] r-x/r-x SM=COW  ...l.app/a-Shell
>
> Termination Signal: Segmentation fault: 11
> Termination Reason: Namespace SIGNAL, Code 0xb
> Terminating Process: exc handler [873]
> Triggered by Thread:  7
> ```
>
>  ```
> Thread 7 Crashed:
> 0   libLLVM                       	0x000000011ac0b3ac 0x11aa70000 + 1684396
> 1   libLLVM                       	0x000000011ac0b3ac 0x11aa70000 + 1684396
> 2   libLLVM                       	0x000000011ac0a654 0x11aa70000 + 1680980
> 3   clang                         	0x0000000118a6a4fc 0x1179b8000 + 17507580
> 4   clang                         	0x0000000118a65e34 0x1179b8000 + 17489460
> 5   clang                         	0x0000000118cac278 0x1179b8000 + 19874424
> 6   clang                         	0x0000000117b91770 0x1179b8000 + 1939312
> 7   clang                         	0x000000011978c108 0x1179b8000 + 31277320
> 8   clang                         	0x00000001197284b8 0x1179b8000 + 30868664
> 9   clang                         	0x00000001181719e8 0x1179b8000 + 8100328
> 10  clang                         	0x00000001179ff258 0x1179b8000 + 291416
> 11  clang                         	0x00000001179fdc8c 0x1179b8000 + 285836
> 12  clang                         	0x00000001179fd7c0 0x1179b8000 + 284608
> 13  ios_system                    	0x000000010106f9ec 0x10105c000 + 80364
> 14  libsystem_pthread.dylib       	0x00000001e2d84bfc _pthread_start + 320
> 15  libsystem_pthread.dylib       	0x00000001e2d8d758 thread_start + 8
> ```
>
>  ```
> Binary Images:
> 0x100ea4000 - 0x100fa3fff a-Shell arm64  <88956ced9ba437d88874ba38cc57427e> /var/containers/Bundle/Application/86CDE0DF-BA4F-48FC-81C7-69FFE57C266C/a-Shell.app/a-Shell
> 0x10105c000 - 0x101073fff ios_system arm64  <2a600cbb4ddd34c2adfde7d5935447d5> /var/containers/Bundle/Application/86CDE0DF-BA4F-48FC-81C7-69FFE57C266C/a-Shell.app/Frameworks/ios_system.framework/ios_system
> 0x10116c000 - 0x101177fff libobjc-trampolines.dylib arm64e  <bc30b5bd95c23ac1972f6d7eeb3d252f> /usr/lib/libobjc-trampolines.dylib
> 0x101318000 - 0x10138bfff dyld arm64e  <b8adece0d2cc3c958d01c5fa21bc74ea> /usr/lib/dyld
> 0x1179b8000 - 0x119a1ffff clang arm64  <91b77adf969f34c8b7287a0b7fe11038> /var/containers/Bundle/Application/86CDE0DF-BA4F-48FC-81C7-69FFE57C266C/a-Shell.app/Frameworks/clang.framework/clang
> 0x11aa70000 - 0x11cf93fff libLLVM arm64  <46390f69e7cb36fd98844c6164b4e274> /var/containers/Bundle/Application/86CDE0DF-BA4F-48FC-81C7-69FFE57C266C/a-Shell.app/Frameworks/libLLVM.framework/libLLVM
> ```



> Hi, thanks for the report; I can confirm that this example also fails on my machine. I'll see if I can fix it. Update: it does not fail when running in Debug mode, which would point towards non-initialized variables.
>
> Out of curiosity, how did you arrive at that example? Would any non-existant command also produce the issue?



> Hi,
>
> I'm using an Apple Security Research Device and working outward to points of impact. Then, I'm running the Reproducer on retail Run Targets to Confirm & Report.
>
> * running in Debug mode, which would point towards non-initialized variables.
>
> Yes, I noted this in my updated Feedback to Apple. I am now making Reports downstream to IOS Projects where the Community can evaluate the issues transparently and I can cull the Results.
>
> -Out of curiosity, how did you arrive at that example? Would any non-existant command also produce the issue
>
> The PoC was found circa 2015 in LLDB Bug Reports from myself and others, I was not the original Reporter, but performed significant Fuzzing at that time which still has a Corpus that delivers PoC Crashers across the XNU ecosystem. I too am looking at the non-existant command issue. Apple so far is No-Fix on this issue so I am now Reporting the Issue to Downstream Projects.
>
> The Feedback Case == FB9591834 with Subject == 20G95 | 13A5212g | clang-1300.0.29.3 | Logic Bug | PoC | Segmentation fault: 11
>
> Please let me know if I can provide any additional information.
>
> Thank You!



> New



> Hello-
>
> Here is another Crasher PoC. It will need to be run a few times to generate the Crash. This is another circa 2015 CLANG Crasher that has been won't fix like the other PoC. I've tested this on iPad 12 Pro, iPhone 12 Pro both running Retail iOS15, and also verified on SRD running iOS 15.1 Beta.
>
> echo "g34( struct Yunsignedp char32_t=char32_t_35==ZcregisterZtypename&&S=4autobitand8 &&or* xor{static_cast&char32_t&welseconst auto" | clang -x c++ -


More information about the cypherpunks mailing list