Skip to content(if available)orjump to list(if available)

One Bug Wasn't Enough: Escalating Twice Through SAP's Setuid Landscape

jmclnx

Looking for and finding bugs and security issues with SAP can consume your time 24/7.

When left a fortune 500 company 2 years ago, many SAP processes were running in background on UN*X with these arguments:

-u USERID -p PW

As a developer I informed the admins a couple of times over the years, the response was "wow, will check it out". But they ran into a mountain of red tape and gave up. So nothing was ever done.

But as a developer and support person, at least I had a way to fix things without falling into the bureaucracy quicksand. FWIW, I only had to do that twice over a 10 year period around Q/E.

depierre

SAP can mean so many things that it's easy to get lost in the weeds, and I'm just talking about getting familiar with their landscape... While working on that post, I found new vulnerabilities that SAP is now addressing.

I'll be honest, I've never been on the other side dealing with red tape. It'd probably drive me mad. But from the researcher/consultant side, it's definitely gotten easier to report vulnerabilities. Vendors now have security contacts, coordinated disclosure policies, and even bug bounty programs. Not all vendors, of course. But compared to 10 years ago, it's night and day.

hinkley

From personal experience, CERT advisories can help cut a lot of red tape. A lot of the wishful thinking and inertia evaporate once the public disclosure goes out.

That is a big part of why there’s so much support for the disclosures. People like me and GP see how little progress gets made without the “Press”.

philjohn

My favourite experience of SAP was a guy I worked with who was part time, 4 days a week.

It always did odd stuff to the rounding of his accrued annual leave - like saying he had 0.99 days left to take, when he actually had a full day.

hinkley

Like using a push broom to keep the flood at bay.

I didn’t realize that SAP was already 12 years old when The Goal was published. And that was a company whose origin story was a divestiture to IBM from Xerox and some of the projects getting cancelled.

I had it in mind based on commentary added to the anniversary edition of The Goal that the whole field of ERP started in the 80’s but it seems that was more correct to say that’s when it exploded, not where it started.

hinkley

There are a number of reasons why the reporting process for bugs needs a blackout window.

Just because a security researcher can discover things about a program that its own developers missed, doesn’t mean they’ve understood the entire picture. If you find one bug, you need to spend time making sure that it doesn’t represent an entire class of bugs. Once the advisory is announced, that’s blood in the water that will attract other predators. Only idiots and tourism companies chum the water before they expect more people to go into it.

Back when PHP was objectively awful, I joined the pitchforks and torches mob based on the litany of CERT advisories against it. I had an argument with a coworker about whether PHP was irresponsible to use, and the very next day someone defaced the phpBB instance he maintained because of an unpatched injection attack. I pointedly did not comment because 1) smug and 2) the timing made me nervous of being accused of having been the perpetrator.

But I did look at the patch that either just came out or that he missed, and was frustrated to find that the same pattern they fixed existed in two other functions.

I really think that it says more about a community, not in what mistakes they make, but how they learn from those mistakes. And I’d like to say it seems like SAP didn’t, but we all know what a beast that thing is. How many tens of millions of lines of code is that thing now? The chances that a person made a mistake and two people they’ve never met copied it are essentially 0.99 repeating.

FredPret

SAP is more of an ecosystem of things than a single thing. But yes, there’s a lot of code there.