Problem on M1

[Vladimir K]

Используем ключи SenseLock EL4S-RTC64K). Рапортует мой коллега:

There is a crash in S4Enum (probably buffer overlow) when the dongle is connected via USB hub.
Here is an example running SLcheck tested on M1, with the dongle connected over a USB hub:

(lldb) r
Process 4613 launched: '/Users/tihmstar/dev/dongleprotection/Build/Products/Debug/SLcheck' (arm64)
Process 4613 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1b9ae4b6c)
frame #0: 0x00000001b9ae4b6c libsystem_c.dylib`__chk_fail_overflow + 24
libsystem_c.dylib`__chk_fail_overflow:
-> 0x1b9ae4b6c <+24>: brk #0x1

libsystem_c.dylib`__chk_fail_overlap:
0x1b9ae4b70 <+0>: pacibsp
0x1b9ae4b74 <+4>: stp x29, x30, [sp, #-0x10]!
0x1b9ae4b78 <+8>: mov x29, sp
Target 0: (SLcheck) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1b9ae4b6c)
* frame #0: 0x00000001b9ae4b6c libsystem_c.dylib`__chk_fail_overflow + 24
frame #1: 0x00000001b9a7bf0c libsystem_c.dylib`__strcpy_chk + 108
frame #2: 0x000000010000a228 SLcheck`UpdateDeviceInfo(pKeyList=0x0000000100809200, dwKeyCount=1, type=1) at utils.c:476:4 [opt]
frame #3: 0x000000010000a130 SLcheck`UpdateItokenDeviceList at utils.c:0 [opt]
frame #4: 0x000000010000e070 SLcheck`SKeyListKey(ctxList=0x0000000000000000, ctxLen=0x000000016fdff430) at itoken.c:86:2 [opt]
frame #5: 0x0000000100007fbc SLcheck`S4Enum(s4CtxList=0x0000000000000000, lpCtxListSize=0x000000016fdff430) at sense4.c:239:18 [opt]
frame #6: 0x000000010000677c SLcheck`KeyOpenAndAuthenticate(outCtx=0x000000016fdff470) at libSLcheck.c:126:12
frame #7: 0x00000001000050fc SLcheck`main(argc=1, argv=0x000000016fdff680) at main.c:30:12
frame #8: 0x00000001000450f4 dyld`start + 520

Looks like the bug is in UpdateDeviceInfo function.
Basically their DEVICE_INFO object. Has an element named char devicePath[0x104].
But if you're on M1 mac and the dongle is connected via USB hub, the DevicePath is much larger (in my instance it is 0x151 bytes).
The problem is they are calling unbounded strcpy (Or maybe they meant to call strncpy ?) which overflows the object!
But without going too much into detail on how everything should be re-writte, a (really bad) hotfix would be to make the struct element much larger (e.g. 0x1000 bytes in size).