Search This Blog

Tuesday, March 22, 2011

SAP Note 1133739 - Security note: Security gap in Data Browser (SE16)





Symptom

Transaction SE16 is a universally applicable function to display any database contents in ABAP systems.
An authorization check against a table authorization group protects the access to this data using this function (authorization object S_TABU_DIS).

If you use transaction SE16 in a certain way, the system may fail to perform this authorization check.  This may allow unauthorized access to any sensitive or critical data.

The correction (Support Package or correction instructions) solves this problem.

Risk mitigation before the correction is effective:  Limit the access to transaction SE16 (authorization object S_TCODE).
We strongly recommend that customers limit the access to SE16 and implement the correction instruction as soon as possible.



Other terms
Data Browser, SE16


Solution
Use transaction SNOTE to implement the corrections.





Affected Releases
Software
Component
Release
From
Release
To
Release
And
subsequent
SAP_APPL
30
31I
31I
 
SAP_APPL
40
40B
40B
 
SAP_APPL
45
45B
45B
 
SAP_APPL
46
46B
46B
 
SAP_BASIS
46
46B
46D
 
SAP_BASIS
60
620
640
 
SAP_BASIS
70
700
700
 
SAP_BASIS
71
710
711
 


Correction delivered in Support Package
Support
Packages
Release
Package
Name
SAP_APPL
31I
SAP_APPL
40B
SAP_APPL
45B
SAP_BASIS
46B
SAP_BASIS
46C
SAP_BASIS
620
SAP_BASIS
640
SAP_BASIS
700
SAP_BASIS
710
SAP_BASIS
710
SAP_BASIS
711

Corrections Instructions
Correction
Instruction
Valid
from
Valid
to
Software
Component
Last
Modifcation
40B
40B
SAP_APPL
12.02.2008  08:22:46
 
 
SAP_BASIS
18.01.2008  13:07:48
46C
46D
SAP_BASIS
01.02.2010  09:33:52
620
620
SAP_BASIS
25.06.2008  13:52:28
640
640
SAP_BASIS
18.01.2008  14:27:22
700
700
SAP_BASIS
18.01.2008  14:27:54
710
710
SAP_BASIS
30.01.2008  16:00:41
710
710
SAP_BASIS
25.06.2008  08:31:51
711
711
SAP_BASIS
25.06.2008  08:32:07
31I
31I
SAP_APPL
18.01.2010  09:01:21
45B
45B
SAP_APPL
18.01.2010  09:03:32
46B
46B
SAP_BASIS
01.02.2010  09:21:23

SAP Note 1023437 - ABAP syst: Downwardly incompatible passwords (since NW2004s)

Validity: valid since 07.02.2007



Symptom
Password-based logon attempts (to ABAP systems as of Release 7.00 / NetWeaver 2004s / SAP ERP 2005) fail, although the user has entered a supposedly correct password in a front end component or in a destination (of another system).
However, a (direct) SAPGUI logon with the same password is successful.



Other terms
USR02, CODVN, BCODE, PASSCODE, hash password, logon password


Reason and Prerequisites
As described in Note 862989, ABAP systems as of NetWeaver 2004s (7.00) support passwords of up to 40 characters, whereby they differentiate between uppercase and lowercase.
In earlier ABAP Releases (prior to 7.00), passwords could only be comprised of a maximum of 8 characters, whereby lowercase letters that were entered were
automatically changed to uppercase letters.

If, in a newer ABAP system (as of Release 7.00), a downwardly
incomplatible password is unknowingly granted (see below), and if the front end or middleware components are not able to process such passwords correctly, logon problems inevitably occur. This is usually due to the (invisible) automatic conversion from lowercase to uppercase letters.
The problem is due to the fact that the password entered by the user does not arrive at the server in the same form, but is changed either during input or during the transmission (in which many components are involved).

Term definitions
  • Password: downwardly compatible / downwardly incompatible

    A (plain text) password is downwardly compatible if it consists of a maximum of 8 characters
    and contains no lowercase letters.

    A (plain text) password is downwardly
    incompatible if it consists of more than 8 characters or contains at least one lowercase letter.

    Older ABAP systems support downwardly compatible passwords only. In newer ABAP systems (as of Release 7.00), downwardly incompatible as well as downwardly compatible passwords may be granted.
    Since lowercase letters that you enter are now no longer changed to uppercase letters, the passwords granted in newer ABAP systems are normally downwardly incompatible.
  • Hash password procedure / Code versions

    ABAP systems do not save passwords in plain text, but instead calculate a hash value and save this together with the meta information using the hash password procedure ("code version"). This information is stored in the user master record and it is analyzed during the password check: A hash value is determined, using the code version specification (from the user master record), from the plain text password to be checked and it is compared with the reference hash value (from the user master record).

    The quantity of the hash password procedure supported is release-dependent, whereby newer releases always support all procedures of preceding releases. This ensures that a password logon is also possible after a release upgrade.

    Only the hash password procedures available as of Release 7.00 also support the processing of downwardly incompatible passwords. Older hash password procedures support downwardly compatible passwords only.

    Whether downwardly incompatible passwords are supported or expected during a password logon depends primarily on the specifications (code version) saved in the user maser record.
Solution
  • When using the technical user (in RFC destinations):
    We strongly recommend that you use the SYSTEM user type on the server (or also SERVICE, provided a SAPGUI capability is required), since the password has unlimited validity only for these user types (see Note 622464).
    If the password should be  entered in an RFC destination of an older system (= RFC client), it
    must be granted as a downwardly compatible password on the server. For users of the SYSTEM or SERVICE type, this is always possible, even if the password rules of the system normally compel the use of downwardly incompatible passwords (for example, by login/min_password_lng > 8 or login/min_password_lowercase > 0).
  • When using older front end or middleware components and password logon of "normal" user (DIALOG type):
    In this case, it is not practical to change the passwords of the (numerous) users affected ( as in the above case with technical users). Instead you must replace the obsolete front end or middleware components.
    Note 792850 describes as of which version level certain front end or middleware components support the interaction with downwardly incompatible passwords.
    In addition, you may need to update other software components (attached to these components), as well as those  of external providers. This is particularly the case if these components lead their own password input dialog and are not able to support downwardly incompatible passwords (according to the above definition of the term).
    For the moment, you can set the profile parameter login/password_downwards_compatibility on the server to the value 2 or 3 for test purposes. In this case, the server checks if the client has sent a matching downwardly compatible password for the expected downwardly incompatible password (that is, a password that is 8 characters long and converted to uppercase). If this is the case, it is logged in the sys log (for error analysis purposes), and the logon is assessed as successful (for value 3). Using transaction RZ11, you can change the profile parameter dynamically, that is,  without restarting the system.
Affected Releases
Software
Component
Release
From
Release
To
Release
And
subsequent
SAP_BASIS
70
700
700
X
SAP_BASIS
71
710
710
 

SAP Note 991968 - Value list for login/password_hash_algorithm

Validity: valid since 21.01.2009



Symptom
With SAP NetWeaver 7.1 (SAP_BASIS 7.10) or  SAP NetWeaver 7.0 Enhancement Pack 2 (SAP_BASIS 7.02), the list of supported hash value password processes was extended: In addition to the processes of previous releases, the NetWeaver Application Server ABAP (NWAS ABAP) now also supports hash value password processes for which a randomly generated value ("random salt") is used to calculate the hash value.


Other terms
SSHA1, salted SHA-1, RFC-2307, RFC-3112, USR02-PWDSALTEDHASH


Reason and Prerequisites
All the data required for calculating the hash value password process (the used hash algorithm and the salt value determined for the assignment of the password) are saved in a defined coding process in a text string.
During the password check, this text string is split into the parts mentioned above and a hash value is calculated using the plain text password. This hash value is checked for similarity with the reference hash value saved in the user master record.
By using (generic, self-descriptive) text strings you can support further hash value password processes in the future. All you need to do this is a new kernel version. You no longer have to adjust data structures to store password information.



Solution
This note provides an overview over which kernel versions support which hash value password processes or which coding processes. Furthermore, the note also provides information about what data is required for the login/password_hash_algorithm profile parameter or which data is analyzed in this parameter.

This note is updated regularly.

At the moment, only one hash value password process is supported:

  • iterated salted SHA-1

    Available as of: Kernel 7.10
    (SAP NetWeaver 7.0 Enhancement Pack 2 uses kernel 7.20)

    The default values for the login/password_hash_algorithm profile parameter as as follows:
    encoding=RFC2307, algorithm=iSSHA-1, iterations=1024, saltsize=96

    Value range for "iterations":  1 - 4294967294 (2 ^ 32)
    Value range for "saltsize": 32 - 128

Affected Releases
Software
Component
Release
From
Release
To
Release
And
subsequent
SAP_BASIS
70
702
702
X
SAP_BASIS
71
710
720
X

SAP Note 874738 - New password hash calculation procedure (code version E)

Validity: valid since 11.10.2005





Symptom
Previous password hash procedures (code versions B and D) may cause the following error scenarios:
  • Users whose passwords contain certain special characters (for details: see below), may also log on to the system using changed passwords: it seems that the system treats all special characters equally.
    (For more information: see Note 735356)
  • When calculating the password hash values the system under certain circumstances does not take into account all characters of the password (the password is actually truncated). This applies to both the old password hash procedure (code version B) and the new password hash procedure (code version D) that was implemented with Note 735356; with the usage of non-ASCII characters or Unicode characters this problem occurs more often.

Other terms
USR02-CODVN, UTF8, hash collisions


Reason and Prerequisites
The reason is an incorrect implementation in the kernel (password code versions B and D).


Solution
Use a new kernel and a Support Package/a correction instruction:
  • Systems with SAP_BASIS 4.6x:
    Kernel 4.6 as of patch number 2121.
    In addition, read Note 318846 (usage of a downward-compatible kernel).
    In addition you should implement the ABAP corrections from Note 735356.
  • Systems with SAP_BASIS 6.x:
    Kernel 6.40 as of patch number 90.
    In addition read Note 664679 (usage of a downward-compatible kernel).
    In addition you should implement the ABAP corrections from Note 735356.
  • Systems with SAP_BASIS 7.0:
    Kernel 7.0 as of patch number 23.
    In addition you should implement the ABAP corrections from this note.

For Systems with Basis Release 3.x, 4.0 or 4.5 no solution is available (since UTF8 is not supported prior to kernel Release 4.6).

For systems as of Basis Release 7.0 the password code versions B, D and E are actually only of interest because of the downward compatibility. As of Release 7.0 new (downward compatible) password code versions (F and G) are supported, which allow the usage of longer passwords (of up to 40 characters), where an additional distinction will be made between uppercase and lowercase letters.
For more information , see Note 862989.



Remark when using the Central User Administration (CUA)
As already described in Note 735356, the implementation of a new password hash procedure (here: code version E) is a change that may cause problems when using a Central User Administration (CUA). It must be ensured that all participating systems of a Central User Administration support the new password encoding procedure (through the usage of the combined ABAP correction and kernel correction). You may only activate the new procedure by setting profile parameter login/password_charset to value 2 (see Note 735356) if this is true.


General restrictions when using the password hash procedure in non-Unicode systems
Some (European) characters exist both as lowercase and as uppercase letters. However, in some code pages in non-Unicode systems only the lowercase letters of some characters exist (for example, Latin-1: characters µ (0xB5) and ÿ (0xFF)); the related uppercase letter character does not exist in the code page. When converting the password to uppercase letters, these characters are not converted (in non-Unicode systems); in Unicode systems, however, the characters are converted. As a result, it can happen that users who have passwords that contain such characters cannot log on to the system with their passwords after an upgrade from a non-Unicode system to a Unicode system.




Affected Releases
Software
Component
Release
From
Release
To
Release
And
subsequent
SAP_BASIS
46
46C
46D
 
SAP_BASIS
60
610
640
 
SAP_BASIS
70
700
700
 

Correction delivered in Support Package
Support
Packages
Release
Package
Name
SAP_BASIS
700

Corrections Instructions
Correction
Instruction
Valid
from
Valid
to
Software
Component
Last
Modifcation
700
700
SAP_BASIS
07.10.2005  14:29:19