nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
IBM: Yes, it's true. We leaned on researchers to censor exploit info

Silver badge
Windows

"Okay -- so they fixed it right?"

"and well -- no one really knows what all that mumbo jumbo in the exploit log *really* means"

" soo .. we don't need to apply that patch, really, its too much bother to schedule a change and plan a patch, and its not like its *that* easy to use...."

Hey: IBM. ITS NOT YOU! -- you fixed the damned issue - and if you WANT to get your customers secured, which I'm sure you DO, you need them to WANT to apply the patch. POC in the wild is the ONLY lever that can be used on some of those .....*cough* customers of yours.

Yeesh. But then, I should expect that the stupid has saturated down very many levels now....

9
2
Anonymous Coward

Re: "Okay -- so they fixed it right?"

What?

3
0

A wizard should know better...

...as Gandalf used to day in similar situations.

0
0
Silver badge

Re: A wizard should know better...

Not Gandalf, Treebeard, in reference to Saruman damaging the forest.

3
0

Re: A wizard should know better...

True, but still IBM should know better.

2
0

Seeing as there are still ancient versions of WebSphere still in production out there I get why IBM didn't want it published, any idea how far back the bug goes?

4
0

IBM already published the full exploit details

They issued a patch, and a description of the class and severity of the vulnerability it addresses. Reverse-engineering of patches is a long-established practice (figure out what got fixed, then often the attack becomes obvious, if not start exploring the changed area) and the severity info tells you how juicy a target it is.

4
0

I don't see any "shaming" or "censoring" here...

IBM's request was made informally, but it was polite, and not phrased as a demand or threat. Perhaps both you and the researcher are reading a little too much into it.

4
4
Silver badge

Re: I don't see any "shaming" or "censoring" here...

Probably still not a great idea to ask that pertinent information be witheld.

Sounds a lot like IBM is trying to lessen the perception that they distribute vulnerable code, at least in this case.

2
3

Re: I don't see any "shaming" or "censoring" here...

They weren't calling for the report to be pulled entirely; anybody that cared to look could plainly see that the exploit existed.

4
0
Anonymous Coward

Re: I don't see any "shaming" or "censoring" here...

WARNING!!! BULLSH*T DERAIL DETECTED!!!

Honestly, I posted because I think you both are right and that sounds like a competent business model.

BULLSH*T IMMINENT!! BRACE!!!

By reading this article, ya'll stealing Microsoft's thunder!!!

0
0
Silver badge

Re: I don't see any "shaming" or "censoring" here...

This kind of "request" is exactly why full disclosure was birthed; no transparency anywhere.

FWIW my understanding IBM were informed of the issue responsibly back in may. IMHO companies who sit on patches for that long, lets call them IBM's customers, probably need the beating to get their house in order. Nothing is achieved by pandering to stupid.

1
1
Gold badge
FAIL

So conspiracy or cockup?

Cockup.

Over eager IBM bod thinks this is a big deal and doesn't want anyone to know.

Conspiracy.

A big IBM customer cannot/will not update their Websphere installation asks them to suppress details so they don't have to spend the money to do what they should have done.

Key lesson.

Every bit of software you don't write may have to be removed/upgraded/patched and you should have some kind of plan to do so. Think of it as the software operations life cycle.

7
0
Silver badge

One correction needed

Every bit of software you don't write may will probably have to be removed/upgraded/patched and you should have some kind of plan to do so.

Which is why I find it so disturbing when people ship "un-upgradable" software and (even more commonly) firmware. Like most IoT crap.

6
1
Silver badge
Holmes

Re: One correction needed

I want to see a standard clause in EVERY software maintenance contract - "Vendor undertakes to recertify and update their software against any flaws AND patches or updates to software platforms on which the Vendors product depends".

I appreciate this will increase the cost of a maintenance contract; If it costs the vendor $1m to recertify each Patch Tuesday and they only have 1000 customers, that means £12k p.a. added to the cost of a maintenance contract. But cheaper than the £50k I was once quoted for a one-off exercise to satisfy my risk-averse company that installing an OS patch bundle wouldn't break $VENDORs application.

It needs more work - for example, I don't know how it would help someone locked into Windows XP, but it should get vendors and customers thinking more about maintainability and upgrade paths.

1
1
Silver badge

Re: So conspiracy or cockup?

> Cockup.

> Conspiracy.

Deadlines.

My (and many other people's) policy used to be that if I found something I'd give the outfit in question 30 to 90 days to issue fixes before publishing. This was in response to some outfits never fixing things and demanding that vulnerabilities be embargoed until they were.

Once "certain outfits" started getting gag orders to keep things quiet, the politeness of giving them a heads-up went out the window. Liability for creating vulnerabilities lies with those who create them, not those who discover and publicise them. Reacting to a headsup with hostility means that you've burned your bridges with the security community and should expect to be treated accordingly.

0
0

Conflicted on this

I sympathize with both parties. A company in IBM's position can absolutely have a legitimate concern that keeping the worst parts (eg exploit code) offline during the initial disclosure will prevent some of their customers from being exploited. Perhaps after some nominal timeframe they can "un-embargo" it.

And while full disclosure is a nice philosophical goal, I've seen more than my fair share of "security researchers" over the years who seem more determined to make a name for themselves by releasing documentation and tools to facilitate widespread malicious behavior via copycats than they truly seem interested in improving the security of the digital world.

I don't know what category Maurizio Agazzini comes under. But likewise, not every company that thinks in the way IBM is here is automatically some cartoonish caricature of the sleazy, profit-hungry monster that only cares about their bonuses and golden-parachutes.

8
2
Anonymous Coward

Re: Conflicted on this

I'm conflicted too. I used to work for IBM, hence A/C and in my experience there are some customers who are very well looked after, with dedicated IBMers to hand-hold them through situations like this. Others are left entirely to their own and will only learn of the patch if they happen to spot the email (assuming they have set that up) amongst all of the spam they get from IBM.

At the same time, the way many IT departments are run is abysmal. In fact, I'd say most. So-called 24x7x365 operations which can't have downtime, yet they haven't factored in provision for code upgrades, or even failures. They will run entirely at risk of total meltdown, because someone suggesting a small outage to apply a patch, or heaven forbid, spending some money to implement a resilient solution to keep the business going, will be accused of incompetence. So everyone keeps quiet and hopes the worst won't happen. If it does, the blame will be shifted to someone else, hopefully a former colleague, or the suppliers.

Some IT departments have impressed me by the way they get it right, but most haven't. Yes, they'll have strict change-control procedures, which won't let you fix something that's offline until everyone important but clueless puts his or her signature to it. But they'll assume they're right and you're wrong.

7
0
Bronze badge
Megaphone

Some people just want to stick it to em

So

researcher approached ibm about the flaw,

ibm worked with them to fix the flaw

Ibm released the fix to the public

IBM knowing their customers can't just apply a patch like it's some trivial ms patch asked for the exploit code to be removed to give their customers extra time to test validate and implement the patch on the systems their customers rely on.

I think it's entirely reasonable for IBM to ask, and shows huge responsibility, credibility and maturity of the researchers to comply. The details are out there for all to see, ibm obviously deemed it enough of a threat to go to the effort of patching the system legitimising the researchers claims, therefore no need for exploit code to be available for hackers to easily use, the hackers should write their own exploit code or buy from the researchers.

If you don't ask you don't get.

4
4
Facepalm

Re: Some people just want to stick it to em

then they should have asked the researchers to publish the exploit, say, 4 weeks after the patch is available

they already were in contact with them before!

1
0
Bronze badge
Facepalm

Next time

The effects of IBM gagging part of the information release is in the future when someone finds a bug with IBM software, they will likely not tell IBM before posting the info publicly. This is where they shoot themselves in the foot.

Unless there is a well paid bug bounty of course.

4
1
Anonymous Coward

Re: Next time

If any deep thinking was going on during those big blue management meetings, someone would have already figured out that it's a better idea to invest in bug bounties and fix problems while working with others to create real solutions. Of course, it requires actually seeking a solution to a problem, in order to find one. There are ways to waist time and money. Management meetings is among them.

1
1

What? So "Watson " didn't use any of that cloud clustered power node blade center multiple PDU'd High performance computing to deduce how bad of an idea this was? So much for AI. Or was it the result of a management meeting that included the kind of lunch that requires a nap, afterward?

1
0
Anonymous Coward

Oh wait, we can charge for the source code. And if we work it out right, we can add a consulting contract for various services that include this, that, and whatever else we need...

1
0
Anonymous Coward

HOLD UP. You can't just come up with new ways to bill customers for service fees just because you want them? What value do they add? What are you actually DOING for that customer to earn those fees?

1
0
Silver badge
Facepalm

I assume you would have used the joke icon if you hadn't posted anonymously. This is SOP for Oracle and many others.

2
0

If you've ever dealt with IBM Security you'll know that they like to be condescending, unpredictable, and it seems policy can be made up on the fly with anyone with "Security" in their title. Someone had a bit too much sugar on the morning cornflakes at IBM and this is the result, nothing unusual to see here.

3
2
Silver badge

Wait

From Agazzini's public announcement:

"6. Timeline

20/08/2016 - First communication sent to IBM PSIRT (psirt at us.ibm.com)

22/08/2016 - IBM Response, PSIRT Advisory 6345 assigned to the bug

05/10/2016 - Communication from IBM with fix information (PI62375)

07/10/2016 - Security Advisory released

Copyright (c) 2016 @ Mediaservice.net Srl. All rights reserved."

Maurizio Agazzini CISSP, CSSLP, OPST"

So IBM received notice on August 20, developed and tested a correction by October 5, and released the advisory on October 7, whereupon Agazzini immediately announced the details to the world.

Many shops have a regular patch cycle that varies in length, but would be unlikely to be less than a couple of weeks except for tiny organizations or very easily exploited patches with very high impact. Most have internal requirements for testing, even of security changes, and a patch cycle of a month probably is fairly common. Publicly releasing details of a major commercial product vulnerability on the same day that the fix is released falls well short of my idea of responsibility unless the vulnerability already is known and being exploited or a trivial mitigation can be applied until the full correction can be tested and installed.

There may be mitigating circumstances like vendor foot dragging, but this case does not show it. IBM moved from notification to correction release in seven weeks, which is not necessarily unreasonable.

2
0
Silver badge
WTF?

resource exhaustion ?

In Webshere ? IMHO and bitter experience it's feature not a bug. How would one distinguish between attack and normal operation?

0
0

Q3 earnings announcement

...probably more related to how close this negative press is to their Q3 earnings announcement...

1
0

Apparently some people at IBM....

Have not yet learned that once published on the interwebs it will be out there FOREVER. Maybe not on the wayback site, but it's out there somewhere.

0
0
Anonymous Coward

Pesky Customers, Skip the Holidays and Patch!

Customers have a great reluctance to apply patches in the last 3 months of the year-- between people going on holiday and an increasing tide of sales business, you really don't want to break anything with a patch. The Italians (or anyone in Europe) should understand this pretty clearly, what with Euro penchant for huge heaps of holidays, not synchronized with the rest of the world, so that at any one time in the last 3 months probably 1/3 of the first world is on holiday... until Christmas through New Years, when most of the first world is running 3rd string skeletons.

IBM should have asked for a delay until mid-1st quarter 2017... anyone not patched by then probably isn't going to patch.

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing