What Can We Learn From The Recent Glibc Flaw?

Has the Internet’s Library left the door open to hackers?
Researchers at Google and Red Hat announced back in February that they had found a terrifying flaw in the internet, leaving many devices and software vulnerable to remote hijacking. Hundreds of thousands of apps and hardware were immediately at risk of being attacked and taken over. The researchers found the flaw inside the Glibc (GNU C Library) which is used by the open source operating system GNU and GNU/Linux. It is also used by countless other systems which are based on Linux. Glibc is so widely used that at the time every Linux machine found itself at risk of being overthrown by hackers.
So what does this mean for server security?
Iain Thomson of The Register warned how “simply clicking on a link or connecting to a server can lead to remote code execution, allowing scumbags to steal passwords, spy on users, attempt to seize control of computers, and so on. Any software that connects to things on a network or the internet, and uses glibc, is at risk.” As could be expected, the sheer numbers of machines potentially affected caused panic among the developer community as well as a large number of VPS.NET customers who ran Glibc on their virtual servers.
Thankfully the VPS.NET server management team had the Glibc flaw patched in no time, and VPS.NET customers were able to continue their hosting activity without further danger.
Where did Glibc come from?
The GNU Project was introduced in 1983 by MIT’s Richard Stallman, offering free, open source software to all. It led to the first free software based operating system: Linux. The glibc is: “the GNU Project’s implementation of the C standard library.” It also directly supports C++.
Google and Red Hat researchers found the flaw independently of each other. Apparently, during a debugging project, a Google researcher “discovered a segmentation fault every time he tried to connect to a specific host. When a program is trying to read or write an illegal memory location, a segmentation fault causes programs to crash”.  Further investigations found that all versions of glibc upwards of 2.9 were affected.
Google researchers defined the flaw as: “the glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the “getaddrinfo()” library function is used. This unfortunately meant that attackers could use domain names and DNS servers to exploit the hack, or launch man-in-the-middle attacks. A man-in the-middle attack is when an attacker secretly relays and sometimes alters communications between two people or parties who believe they are genuinely talking directly to one another.”
Tech buffs – listen up for a detailed description of the patch from Google:
“glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.
Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.
Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow.
The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.”
To give us a little less worry, they do add that even though the effects can be dangerous, the hacking itself is not that simple; security mitigations would need to be circumvented.
Interestingly, Iain Thomson notes that the glibc bug had already been reported last year in July 2015. His research did not lead to any conclusions about whether or not any actions had been taken to correct the problem. He did find it was classified as “P2 normal”, which indicates it was not seen as a high priority problem.
So what can we learn from this? Any server managing VPS.NET customers should be aware of the various vulnerabilities that can be found in your software; a proactive approach to server security is vital if you want to protect your personal information. All servers which are managed by VPS.NET were patched appropriately during the infancy of the flaw announcement, as here at VPS.NET we take your server security very seriously.
If you wish to speak to someone about this flaw or any other potential flaws in your software do not hesitate to contact us via this webpage.