Untitled attachment

Notices where this attachment appears

1. Embed this notice
   Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 15-Apr-2025 03:46:16 JST Will Dormann

   in reply to

   Well this is hilarious. When looking closer at Stephen's screenshot, I noticed that he was running Ruby from Windows. That couldn't make a difference, could it??

   YES. If you run the PoC exploit from Windows, heap allocations will start at a low address and the exploit will work just fine. If you run the PoC exploit from Linux (I used Ubuntu), then the heap allocations will happen at a memory range that is too high to work.

   I truly have less understanding of how computers work than I could ever have imagined.

   Note that if you target an ICS system that has one CPU, you get one web process and ASLR will load libdsplibs.so at a different location every time. So you can guess a fixed address and it'll eventually be correct. But if your target ICS has multiple CPU cores, you'll get a fork()'d (but not exec()'d web process, so the memory layout will be the exact same every time. So the PoC would need to vary the guessed load address of libdsplibs.so for each attempt, rather than relying on the changes of the guess to happen server-side.

   Edit: No, as per usual, I've fallen victim to another red herring here.

2. Embed this notice
   Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 15-Apr-2025 03:46:15 JST Will Dormann

   in reply to

   As I dig deeper into this mystery, I've discovered that I'm (as expected) once again mistaken here.

   Yes, the Rapid7 PoC needs Ruby 3.1 or older for it to work right.
   But no, there isn't a difference between Linux Ruby and Windows Ruby here.

   Why was I steered wrong?
   Heap allocations on Linux (ICS) don't simply start at low addresses and grow higher. The allocations will use low addresses if they need to. Why didn't my allocations hit low addresses in all of my early testing? Because my ICS test systems all have multiple cores. Stephen's did not. Also, even in my single-core VMs, I suppose I didn't wait long enough before giving up after notinc allocations happening at high addresses. After seeing allocations happening at high addresses for a while, I incorrectly assumed that low addresses wouldn't be touched.

   So if I were correcting this Rapid7 PoC, I would:

   1. Have the script itself modify the guessed libdsplibs.so base address. Because the Ivanti web process does a fork() without an exec(), every single re-spawned web process will have the exact same memory layout as its parent. As such, ASLR will only randomize anything in the web process once at boot time, and not per time it crashes.
   2. If the target is multi-core, then the heap spray will need to be larger. With the multi-web-process situation you end up with on multi-core ICS systems, the default Rapid7 PoC will not work because any given web process will not get coerced into allocating at low addresses.
   3. I'd probably update the script to work with modern Ruby versions. No need to crash upon attempting to figure out the target ICS version.

   Just to help you all visualize what's going on here, here's a sped-up animation of the allocations happening in the web process when it receives the Rapid7 heap spray. Note that the low addresses aren't touched until near the end. My impatience to wait for the spray to complete led me to draw the incorrect conclusion that low addresses weren't going to get touched.