Skip to Content

I have been following the news on the Shellshock vulnerability the last few days (more information here, here, here, and here) – the vulnerability affects millions of systems and devices. And, a lot of SAP customers run UNIX/Linux systems and consequently have unpatched Bash vulnerabilities that should be patched. But what’s the criticality for SAP customers? Would an SAP customer be vulnerable to application-level attacks taking advantage of this vulnerability? Would an SAP customer with services exposed externally be vulnerable to this type of exploit?

Over the weekend Rob Kelly, a colleague of mine, and I spent some time thinking through security ramifications for our clients; Rob spent some time attempting to exploit this vulnerability at the application level on a NetWeaver Gateway and an ABAP AS system front ended by Web Dispatcher. The good news is, SAP has standardized on the C Shell for a lot of their *NIX scripts, and external services are not script-based. PI/PO developers might use Bash scripts but these normally can’t be invoked directly.

The primary consideration for SAP customer is a separation of duties issue. One of the critical technical separation of duties conflicts is that between development and system administration. With this vulnerability, a developer could release code that allowed them to execute arbitrary commands and thus gain system administrator access.

However, SAP customers following the common sense security practices outlined below would already find they have processes in place to address to address this specific risk:

  1. Removing access for Developers to execute OS level commands in production.
    1. The env command used to exploit this vulnerability is defined in SM69 by default; developers should not have access to make modifications in SM69.
    2. Developers shouldn’t have the ability to set up background jobs that would allow them to pass additional parameters.
    3. Don’t forget to remove the ability to run report RSBDCOS0 in SA/SE38.
  2. Addressing infrastructure security
    1. OS-level logins should be restricted to administrators
    2. Restrict the ability to obtain console level access via firewall – do your users need the ability to SSH to your application or database servers?
  3. Following secure software development practices
    1. Run Code Inspector or a like product to ensure input validation for user defined variables being passed to OS Commands (via function module SXPG_COMMAND_EXECUTE, PI/PO scripts, or otherwise).
    2. Have another developer peer review code for workbench requests as part of your change control process.

While the BASH shell should definitely be patched, having these controls in place should mitigate this risk of shellshock being exploited on SAP systems significantly. Practically speaking, most customers can afford to wait to apply this patch in their SAP landscapes during their normal patch maintenance cycle.

What about you? Has anyone else out there explored the implications of the shellshock in their SAP landscapes?

Note: As mentioned in the comments, SAP has released a note on Shellshock: 2072994 – “ShellShock“ vulnerability (CVE-2014-6271).

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Steve Rumsby

    We patched our systems last week. Since it is just bash that is affected, replacing it is non-disruptive and didn’t involve a reboot or even a restart of SAP – nobody noticed! Given that, you might as well go ahead and apply the patch now. No need to wait. Test in development first, obviously, just in case your environment is different from mine!

    That said, after doing a little analysis we concluded, as you did, that our SAP systems weren’t vulnerable anyway. None of the externally accessible services invoke bash, and our internal development practices are pretty safe. But I’m still glad I applied the patch, just in case I missed something 🙂

    Steve.

    (0) 
      1. Steve Rumsby

        Sorry – my systems aren’t Linux systems. I assume whoever supports your systems will provide the patch to you, along with installation instructions. What flavour of Linux? RedHat? Suse? Just ask Google – search “Redhat shellshock” or “suse shellshock”, or whatever your linux flavour is.

        Steve.

        (0) 
  2. Jelena Perfiljeva

    We’re up to the eye balls in projects but I’ll make sure to ring this article up the ladder to follow up with our hosting provider.

    Hey, thanks for sharing the tips on “breaking the system”. RSBDCOS0, whoa! Finally I can start moving that rounded up penny to my Swiss bank account. 🙂

    (0) 

Leave a Reply