Note 1167258 - Security note: Program RS_REPAIR_SOURCE

[Former Member]

After implementing this note I still have some questions and doubts:

1. what is the purpose of this program, what is the context of its use in a development or other environment as it provides a serious backdoor to the ABAP system ?

2. wouldn't be appropriate to check if the user has developer key (entry in table DEVACCESS) on top of the S_DEVELOP authorization ?

3. even if the note is implemented, in a development environment it is possible to easily change its own code wiping out the effects of the checks implemented by the note

All in all I think you don't need too much phantasy to imagine scenarios when this could pose serious threats to any system.

Any opinions ?

Thank you,

Miklos

[morten_nielsen]

Hi Miklos

Your right - the Program looks kind of scary - It might be a good idea to assign an authorization group to it.

I would also suggest that you post an OSS Message asking SAP about the missing check for developper key, and the purpose of this program.

Regards

Morten Nielsen

[Former Member]

It is a rouge program for emergency repairs - but it should still make the correct authorization checks (also in emergencies...) and require modifiable system settings (to be opened in an emergency).

Developer keys are more of an administrative mechanism - not really security. Even although it does help security, do not rely on not having a developer key to prevent development work.

There are many places in SAP where the system does not check the developer key. A simple example is when you create a transaction in SE93.

Cheers,

Julius

[Former Member]

SE93 - I can understand why there is no developer key check for se93 - as that's just a simple way to link objects and very different from changing source code

The focus of the question is though not the developer key (as that is valid only in development systems) or if it can change its own source code but if there would be a better way to do emergency repairs and/or how to best secure this program.

First of all I think this program should be deactivated in development systems, or to be deactivated everywhere and switched on/off using the switch framework. Secondly I think all changes done through it should be logged and directed to the alert system.

Let's assume this program was used for a situation (legitimate or not) that you were not aware of. How would you detect any changes done through it and what is your estimate on how long those changes would go undetected?

[Former Member]

> ... but if there would be a better way to do emergency repairs and/or how to best secure this program.

There is a workflow feature in the STMS which can be used for this. That would be a better solution than a program with the comment:

*&  USE IT VERY, VERY, VERY CAREFULLY !!!!!!

> First of all I think this program should be deactivated in development systems, or to be deactivated everywhere and switched on/off using the switch framework.

Important is that a user with the correct authorizations cannot run it in production. This is not the only such "tool" which can be used in a development system, and is not the least-secure either, even if it is predestined to become one of the most famous...

It has a cousin called RFC_ABAP_INSTALL_AND_RUN which is also very well known. You need to protect the system from it being used - unless the user is authorized and the client is open. Same thing, except remote enabled RFC as well.

Take a look at the blue button with the Abacus icon in SE30 as well. Same thing.

These are developer tools. At least the checks are now consistent - which is what this patch does.

> Let's assume this program was used for a situation (legitimate or not) that you were not aware of. How would you detect any changes done through it and what is your estimate on how long those changes would go undetected?

You will find it in the SM20N logs. The names of the temporarily generated ones will start with a "!". Also keep an eye on development class $tmp.

Again, if the transaction / program / function module, method makes the correct checks and the user has the correct authority, then it is okay in my opinion as it can be used consistently in your authorization concept.

Cheers,

Julius