ABAP exploit/vulnerability exposed

Firstly, let me just make this disclaimer that I don’t know what the difference between an exploit and a vulnerability is. I don’t know the proper definitions of each, either. I’m pretty sure what I’m about to reveal is not a security flaw though. However, using the information contained herein, a malicious user can wreak a fair bit of havoc on an ABAP system.

Secondly, an even bigger disclaimer: Don’t try this on your system! This article is for informative purposes only, not for you to wreak havoc! OK, here goes:

A colleague of mine has been struggling with a problem that when he tried to syntax-check or activate (which does an implicit syntax check) an ABAP program he was working on, it caused the whole system to stop responding. At first we wouldn’t believe him. Yet his claims proved to be true. Whenever the syntax check was invoked, the process would start consuming system resources to the point that dialog processes all became used up, the system response would suffer tremendously, and the process itself would carry on running until it terminated at OS-level with a ROLL_IN_ERROR visible in the process trace. How is this possible?

I decided to take the code he was working on and paste it into a local program to see if it caused the same problem, and it did. After incrementally adding the lines from the rogue source to find the problem, the bad code turned out to be a recursive data definition; a structure referring to itself. It seems as if this code made the ABAP syntax checker perform an endless, recursive check. The code looks as follows (note the line where the included structure in fact refers to itself):

DATA: BEGIN OF gt_stat OCCURS 0.
        INCLUDE STRUCTURE vicarsdate.
DATA: lv_stat LIKE LINE OF gt_stat. "<-- Problem is here
DATA:   transf TYPE xfeld.
DATA: END OF gt_stat

Because the syntax checker is executed as an ABAP command (SYNTAX-CHECK), I assume that the checker is not written in ABAP, but in a C routine. As such, it was not possible to debug the process to see where the problem was.

Using this, a malicious user with rights to SE37 and access to function group S38E can perform a syntax check with function module EDITOR_SYNTAX_CHECK on such code on a production system, bringing performance to a near standstill and making the system unresponsive for quite a while. While this may not be a big problem, because it is possible to tell who the user is from the process overview, it's nonetheless a real risk, as some companies issue credentials for generic users for administrative tasks to some employees.

We found this problem on a 640 system, and to test whether the problem had perhaps been fixed in later versions, I sent the code to an unsuspecting person (who is hopefully still my friend) to ask if he could see whether the ABAP syntax checker has a problem with this recursive definition on his development system, which I think is 710 or above. He mailed me back to tell me that it had been running for 350 seconds, which was all I needed to know.

So, there you have it. We have reported this problem to SAP, but I'm pretty sure that this must be a known problem. Let's hope they provide a patch for it real soon.

Tags:

9 Responses to “ABAP exploit/vulnerability exposed”

  1. KevinFreese says:

    Yes, indeed I am still your friend and will keep this code in my bag of tricks for when I don’t get my next promotion.

  2. Leon van Zyl says:

    Hey, cool! I tried it and the lights in the room instantly dimmed and we had this block-wide power outage! Thanks for the genius who came up with this bit of code (KevinFreese??)

  3. Thomas Jung says:

    I tried it on a 7.0 SP12 – Kernel Patch level 110 system and I didn’t get the same results. It ran the syntax check for about 5 seconds and then terminated with this message:
    SAP System message: Work process restarted; session terminated

    I got the exact same response on a 7.10 SP3 – After a few seconds the work process is terminated.

  4. admin says:

    Hello Thomas, thanks for sharing your observations.
    Now that you mention it, our sessions also terminated with that message. That makes me think that perhaps the process was terminated due to an SAP-imposed constraint, rather than an OS-imposed one. (Maybe something to do with stack size?).
    Did you look to see what happened to your system resource usage during the few seconds that it ran though? Are you perhaps running your system on a desktop, and with smaller system parameter settings?
    We were running this on servers with many CPUs and GBs of memory, so possibly the constraints are larger and it took longer to reach them.

  5. admin says:

    Hello Leon, thanks for sharing your observations too 🙂 No, the genius who came up with this was not Kevin (although he is a genius in his own right), but another colleague (I will invite him to share his thoughts here). Following on the success of this endeavor, he has decided to vacate his post and apply his genius elsewhere.

  6. Thomas Jung says:

    The 7.0 system I tried it on was a laptop – dual core with 3 gig of memory so it is no slacker in its own regard. I have it tuned as thought it is a small server and not running with the default system parameters of the SDN Preview.

    However the 7.1 system was a nice sized server – certainly on par with some of the average productive systems in the world (it has 6 app servers and the one that I was logged onto running the test is a quad CPU with 8 Gb of memory).

    Both systems took roughly the same amount of time to react to the loop and terminate the work process. I don’t have access to observe the OS monitors on the 7.1 system, but from the process overview I can tell you that the syntax check only ever effected the single work process it was running within and that work process never went into PRIV mode.

    On my local system (7.0) I can more closely observe the OS of course. During the 5 seconds or so that it took before the work process was killed there was no noticable change in resource usage at the OS level. My CPU usage levels remained at approx. 4% and memory usage didn’t fluctuate at all. I looked at the process detail display while the syntax check was running (I caught it about 4 seconds in – so very near the kill point). My work process had 1 roll in with 114Kb of Roll memory and 40Kb of Page. Total memory for the work process was only 6.2Mb.

    In conclusion it appears that the kernel is responding to the loop condition itself and not some side effect of exhausting resources at the OS or App Server level.

  7. admin says:

    Hi Thomas, thanks for the detailed feedback. On checking, I found that my friend’s system was in fact a 7.00 system, and not 7.10 as I thought at first. It’s interesting that your results were so different from ours. It would be interesting to hear results/experiences from other people as well.
    Nonetheless, I think the one thing that emerged from this is that the ABAP syntax checker should ideally recognize self-referencing data definitions, and should raise those as errors.

  8. Nandha Govender says:

    I was the guy who accidently stumbled upon this problem. I added a piece of code as explained by Martin Cerinio. Whenever I did a syntax check it used to take forever. At the same time others around me started to complain of the slow response times. I could not believe that I was causing the problem. I enquired from the more experienced colleagues around me whether I could be the culprit. Jokingly they called me the ‘system breaker’ but did not believe that my actions was causing the problem. We somehow agreed that my action was merely high-lighting a shortcoming in the system in term of the lack of resources in development.
    I refused to check my code as we have a syntax checker to do just that.
    It was only when Martin Cerinio went through my code, and by executing it picked up the problem. It was a recursive call to itself- something that the syntax checker could not handle. Now we know that one could break the system by invoking the syntax checker. There is never a dull moment in ABAP ! Basis was having a torrid time in first pinpointing the problem and seconly trying to kill the processes started by me.
    Never try this at home or work !!!

  9. John Watt says:

    Hey Martin,
    This is seriously interesting but probably something I will never do! I see you haven’t blogged for ages! Give us an update on your increasing family!
    Cheers, John

Leave a Reply