Comment from Ralph Langner
Time: September 21, 2007, 7:34 am

On the Tipping Point stuff… As some of us had expected, it turned out to be mostly marketing hype. Unfortunately. So there is this software vendor in California (Automated Solutions) that develops and sells an ActiveX control for Windows application developers who want to build custom Modbus clients. This control happens to have a bug. Coincidentally, I happen to know the guys from Automated Solutions personally, and I bet that they came up with a fix next day. So who actually needs the “vaccine” that Tipping Point is advertising? Keep in mind that we’re not talking about millions or even thousands of existing installations, but about a comparatively small customer base that is very well supported by the vendor. Call me biased on this, but I would like to see a company like Tipping Point come up with something of more relevance.

Comment from stephan beirer
Time: September 21, 2007, 8:10 am

If the bug was that buffer oveflow in handling FC8 packets, it looks like the vendors patch was released several days *before* TP’s ‘vaccine’

http://www.automatedsolutions.com/pub/asmbslv/ReadMe.htm

Comment from Ralph Langner
Time: September 24, 2007, 6:08 pm

Fellows, this Tipping Point stuff is driving me nuts. The more I am trying to figure out the problem from a technical point of view, the less it makes sense.

Let’s look at the facts: They fuzzed a Modbus slave ActiveX control and it crashed under certain circumstances (FC 8 with illegal parameters).

That’s the facts. Tipping Point now warns us that A REMOTE ATTACKER could exploit this vulnerability TO EXECUTE ARBITRARY CODE on affected systems.

What’s wrong with this picture? Well, something… First, we’re talking about a Modbus SLAVE ActiveX control, i.e. a software component that Windows software developers use to SIMULATE an automation peripheral using the Modbus protocol. Who is using Modbus slave software on PCs? Well… mostly software companies that don’t want to buy and configure real automation peripherals in their labs. In the real world, there’s no reason to use simulation software, as we have the real thing handy on the shelf.

Anyway, looks like Tipping Point suggests this simulation mockup is vulnerable by a remote attacker who may execute arbitrary code on the affected system. In order to do this, the attacker would have to:

1. Install malware on the victim system that he/she intends to execute

2. Provoke the described misbehavior by connecting to the faulty Modbus slave software from, eh, from where? Looks like the attacker would need to infect some other system which acts as the Modbus client. Ok, this could be the victim system that connects to itself via localhost. So let’s assume that the attacker has installed and EXECUTED some piece of attack software on the victim system that provokes the buggy behavior of the vulnerable software, AND that this vulnerable simulation software is running at the same time WHILE not being connected to some legal Modbus client.

3. Make sure that the execution pointer points to the location of the malware when the crash happens.

All this to attack a system that will most likely not run in a real production environment but in a simulation environment in the lab. Probably in a lab just as Tipping Point’s. Anyway, if I was the attacker intending to execute some piece of malware, I certainly would have preferred a more direct route, just to be home in time for lunch.

The bottom line looks like this. First, this appears to be a publicity stunt (somebody please tell me different). Second, it shows us how bad informed the public is – not the general public, but the “pros”: IBM wants us to believe that the reported vulnerability is associated with a “high risk” (http://xforce.iss.net/xforce/xfdb/36677), which is among the most ridiculous assessments I have come across for a long time. Third, it is counterproductive. We may sometimes blame senior management for several things, but the guys with the grey hair usually sniff exaggeration easily. The more they do, the more we lose credibility.

Comment from Dale Peterson
Time: September 24, 2007, 10:52 pm

Ralph - That is an excellent analysis.

I had commented in my blog entry that it did not appear that Ganesh had any experience with actual SCADA, DCS or PLC’s, RTU’s, IED’s, etc. based on the way he talked about them in his presentation. So it is my conjecture, unsupported by any facts, that they did not know the impact of this vulnerability and didn’t have the experience to do the analysis you wrote up. I don’t think they were trying to hype it up as a big deal that could cause a critical infrastructure system to fail.

It does show that you do not need control system experience to attack control systems, but it may take experience to do more than crash them.

You are right on that exaggeration kills the community when trying to convince control system management and C-level executives. I’m surprised by the ISS/IBM rating because they have a few people that understand control systems.

Dale

Comment from Julian L. Tod Rrushi
Time: September 25, 2007, 8:43 pm

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

In my opinion IBM is quite correct in rating the vulnerability under consideration as being of a high risk. Such a severity metric regards only the vulnerability, i.e. a heap overflow in this case, and not the level of exposure of a vulnerable application. A heap overflow is indeed of a high risk as it allows to control both the memory address and the value to be written in a memory write (or more precisely in two memory writes, in practice). Whether a vulnerable MODBUS slave may be reached by attackers or not is another issue.

Regards,
Julian L. Tod Rrushi
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFG+UhS3JhHvEZ9fsERAtteAJ9An4+W/zwtDuGDz2YddHlUqRlvFwCfYrIN
5i7yFji1TsO3TCjQYagLJO0=
=Umnk
—–END PGP SIGNATURE—–