The vulnerability affects the getaddrinfo() function in a standard C library, which is used to look up DNS entries. SAP administrators will be used to seeing similar function names in the SAP system log or trace files when any DNS lookups fail.
Researchers at Google, and independently at Redhat, have discovered an error in how the function manages memory for the DNS response, meaning that more than 2048 bytes of response data may be stored in a smaller area of memory. The overflow can allow an attacker, who has control of DNS responses to potentially run arbitrary code.
Does the glibc bug pose a risk to my SAP systems?
The threat in the wild is limited as it is not straightforward to use this bug to run arbitrary code, because of other security protections such as Address-Space Layout Randomisation (ASLR), but it is possible and Google have managed to do it.
There is a greater risk of the bug causing a crash and resulting denial of service to users than of anyone actually taking control of the server.
As there is a risk of arbitrary code execution and denial of service, this is an urgent bug that should be patched immediately.
Are SAP systems directly affected by the glibc bug?
Glibc is the GNU C Library providing standard functions to a huge range of software. Any linux server where it is present should be patched, as it will be in use by some software, including non-SAP software and potentially SAP software as well.
For example, you can use the tool `ldd` to check a SAP HANA binary, and see that it uses glibc.
How do I fix it?
Versions of glibc from 2.9 and above are affected by the vulnerability. You can check the version present on your linux server with the command `rpm –qa | grep glibc`
On this server, version 2.19 is present. Note that you should not read the version number as a decimal; 2.19 is two-point-nineteen so it is higher than 2.9 meaning it is affected by this bug.
You can fix the bug by applying the patches to your linux servers. On SuSE you can run `zypper update` and on RedHat, `yum update `
As you can see, this server has new glibc packages available from SuSE today:
If you are working on an SAP HANA appliance and you have any OS or HANA support contract in place with a hardware vendor, you should work with them to ensure these support packages are applied correctly.
In any case, the patches should be applied and tested in development and quality assurance systems before going live in production in line with your organisation’s usual change control process.
How do I avoid similar problems in future?
Security experts recommend regular software updates as the number one solution to ensuring your systems are protected from any bugs that have been discovered. For our managed service customers, we promote the concept of a maintenance plan for all SAP landscapes, which includes patching and updating of all SAP and non-SAP software in the SAP technology stack on a regular basis.
Updating software is seen as disruptive or risky by some organisations, but with a maintenance plan agreed in advance, all stakeholders can be aware and prepared for the work and it will quickly become a very smooth business-as-usual process that also prepares your teams for any more significant SAP upgrade work that you may undertake in future.