Smash Call

[CopperD]

Now that I am no longer crazy busy at work I created my dream LabVIEW function. Call function pointer using no external libraries. I call this function smash call as it smashes the stack using a buffer overflow I found in VISA open. It currently is a one way trip as I didn't do anything to fix the stack.

 

Attached are some pictures. It's going to be a part of the DCG library so I'll include it in my next update. I have the example calling command line but you can make it do whatever you want. If you want to use compiled code loaded from a string you will need to use VirtualProtect to set the page executable or disable DEP Data Execution Prevention. 

 

 

Edited March 21, 2016 by CopperD

[Yair]

That is

 

a) awesome

b) horrible

c) not necessarily in that order.

 

I actually initially thought you meant you pass a VI as a function pointer to be executed from a C call, but I guess you're just executing a C function? The images are kind of hard to follow for someone who isn't familiar with disassembly and how exactly LV runs the machine code, so a video explaining it would probably be better for people to understand.

[ShaunR]

That is

 

a) awesome

b) horrible

c) not necessarily in that order.

 

I actually initially thought you meant you pass a VI as a function pointer to be executed from a C call, but I guess you're just executing a C function? The images are kind of hard to follow for someone who isn't familiar with disassembly and how exactly LV runs the machine code, so a video explaining it would probably be better for people to understand.

 

d) Nothing to do with LabVIEW.

 

I think this is very valuable work but useless from a LabVIEW for Engineers point of view. This is really just showcasing a (zero day?) exploit that will hopefully be addressed in the next update and the "feature" will disappear. I would have preferred a responsible disclosure of the exploit and I expect this will get very little love from the community as I would guess that outside NI R&D the number of people that even understand it, let alone could leverage it, can probably fit in a small family car.

 

It is, however, a splendid example worthy of DEFCON and CeBIT for demonstrating attacks on the niche language called LabVIEW. Hopefully we will see DEFCON videos of LabVIEW RT and PXI boxes being pwnd and machines taking peoples arms and legs off. Maybe then the malaise and complacency around security in the LabVIEW community might be eroded somewhat. To be honest, I expected this sort of thing a while ago but I guess we are only now reaping the benefits of the academic licences

 

Keep exploiting while I go for some more popcorn   . I'm sure there are a couple of eyes on this work just itching to marry it with self expanding VIs 

[CopperD]

The function can be any executable code in program memory. To my knowledge this is the first buffer overflow attack against LabVIEW. It could be abused to run unauthorized code but I see this as rather unlikely. I did find several other buffer overflows that evening but none as easy to exploit for my purpose. (Not all buffer overflows lead to changing EIP) I just wanted a way to call a function pointer natively but now my curiosity has been peaked. 

 

A video would be a good idea.

 

I do agree that this is useless for > 99.9% of LabVIEW developers. That why I posted it under the lounge. Yes you could call this a zero day exploit. If it was a RCE (Remote code Execution) I would have checked if NI actually monitors the security inbox.  CERT only has 4 vulnerabilities listed for NI. It might be a good idea for the community to look into the security of LabVIEW. The part that is worrisome is that I only spend a few hours looking for this Sunday evening.

[CopperD]

To be honest, I expected this sort of thing a while ago but I guess we are only now reaping the benefits of the academic licences

 

Academic license what makes you think that?

[ShaunR]

Academic license what makes you think that?

 

I merely meant that scientist and engineers sat in laboratories really don't care about this sort of stuff. They just want their experiment/machine to work. They choose LabVIEW because they don't have to worry about pointers, memory, stacks and registers - all the crap other languages have to deal with - so the mindset of "how do I break/exploit this?" isn't there.

 

With the introduction of the academic licences - not that long ago - LabVIEW has been exposed to more of those with exactly that mind-set and many are polyglots - not only on Windows but on Linux. I'm not saying you are in academia, just that because of the academic exposure we should see more black, white and grey hats targeting LabVIEW where previously there were next to zero.

[CopperD]

Don't forget the LabVIEW Home license and that targets the hacker crowd. 

 

I have reported the buffer overflow to NI. It is fairly minor so I don't think they will care but let's see. It is more of a neat trick for me. I'll guess I'll need to find a new way to load the EIP once they patch it.   It's like eating my own foot. Maybe I'll get some commendation if I find enough exploits.