Posted by Fermin J. Serna, Staff Security Engineer and Kevin Stadmeyer, Technical Program Manager

Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.

Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users.

That patch is available here.

Issue Summary:

Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack.

The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.

Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

Technical information:

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.

Exploitation:

Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact.

As you can see in the below debugging session we are able to reliably control EIP/RIP.

(gdb) x/i $rip
=> 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req
(gdb) x/a $rsp
0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042

When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril!

Failed exploit indicators, due to ASLR, can range from:

• Crash on free(ptr) where ptr is controlled by the attacker. 
• Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address. 
• Crash reading from memory pointed by a local overwritten variable. 
• Crash writing to memory on an attacker-controlled pointer.

We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development.

Posted by Gerhard Eschelbeck, VP, Security and Privacy

[Cross-posted from the Official Google Blog]

Today is Safer Internet Day, a moment for technology companies, nonprofit organizations, security firms, and people around the world to focus on online safety, together. To mark the occasion, we’re rolling out new tools, and some useful reminders, to help protect you from online dangers of all stripes—phishing, malware, and other threats to your personal information.

1. Keeping security settings simple

The Security Checkup is a quick way to control the security settings for your Google Account. You can add a recovery phone number so we can help if you’re ever locked out of your account, strengthen your password settings, see which devices are connected to your account, and more. If you complete the Security Checkup by February 11, you’ll also get 2GB of extra Google Drive storage, which can be used across Google Drive, Gmail, and Photos.

Safer Internet Day is a great time to do it, but you can—and should!—take a Security Checkup on a regular basis. Start your Security Checkup by visiting My Account.

2. Informing Gmail users about potentially unsafe messages

If you and your Grandpa both use Gmail to exchange messages, your connections are encrypted and authenticated. That means no peering eyes can read those emails as they zoom across the web, and you can be confident that the message from your Grandpa in size 48 font (with no punctuation and a few misspellings) is really from him!

However, as our Safer Email Transparency Report explains, these things are not always true when Gmail interacts with other mail services. Today, we’re introducing changes in Gmail on the web to let people know when a received message was not encrypted, if you’re composing a message to a recipient whose email service doesn’t support TLS encryption, or when the sender’s domain couldn’t be authenticated.

Here’s the notice you’ll see in Gmail before you send a message to a service that doesn’t support TLS encryption. You’ll also see the broken lock icon if you receive a message that was sent without TLS encryption.

If you receive a message that can’t be authenticated, you’ll see a question mark where you might otherwise see a profile photo or logo:

3. Protecting you from bad apps

Dangerous apps that phish and steal your personal information, or hold your phone hostage and make you pay to unlock it, have no place on your smartphone—or any device, for that matter.

Google Play helps protect your Android device by rejecting bad apps that don’t comply with our Play policies. It also conducts more than 200 million daily security scans of devices, in tandem with our Safe Browsing system, for any signs of trouble. Last year, bad apps were installed on fewer than 0.13% of Android devices that install apps only from Google Play.

Learn more about these, and other Android security features — like app sandboxing, monthly security updates for Nexus and other devices, and our Security Rewards Program—in new research we’ve made public on our Android blog.

4. Busting bad advertising practices

Malicious advertising “botnets” try to send phony visitors to websites to make money from online ads. Botnets threaten the businesses of honest advertisers and publishers, and because they’re often made up of devices infected with malware, they put users in harm’s way too.

We've worked to keep botnets out of our ads systems, cutting them out of advertising revenue, and making it harder to make money from distributing malware and Unwanted Software. Now, as part of our effort to fight bad ads online, we’re reinforcing our existing botnet defenses by automatically filtering traffic from three of the top ad fraud botnets, comprising more than 500,000 infected user machines. Learn more about this update on the Doubleclick blog.

5. Moving the security conversation forward

Recent events—Edward Snowden’s disclosures, the Sony Hack, the current conversation around encryption, and more—have made online safety a truly mainstream issue. This is reflected both in news headlines, and popular culture: “Mr. Robot,” a TV series about hacking and cybersecurity, just won a Golden Globe for Best Drama, and @SwiftOnSecurity, a popular security commentator, is named after Taylor Swift.

But despite this shift, security remains a complex topic that lends itself to lively debates between experts...that are often unintelligible to just about everyone else. We need to simplify the way we talk about online security to enable everyone to understand its importance and participate in this conversation.

To that end, we’re teaming up with Medium to host a virtual roundtable about online security, present and future. Moderated by journalist and security researcher Kevin Poulsen, this project aims to present fresh perspectives about online security in a time when our attention is increasingly ruled by the devices we carry with us constantly. We hope you’ll tune in and check it out.

Online security and safety are being discussed more often, and with more urgency, than ever before. We hope you’ll take a few minutes today to learn how Google protects your data and how we can work toward a safer web, for everyone.

Posted by Lucas Ballard, Safe Browsing Team

In November, we announced that Safe Browsing would protect you from social engineering attacks - deceptive tactics that try to trick you into doing something dangerous, like installing unwanted software or revealing your personal information (for example, passwords, phone numbers, or credit cards). You may have encountered social engineering in a deceptive download button, or an image ad that falsely claims your system is out of date. Today, we’re expanding Safe Browsing protection to protect you from such deceptive embedded content, like social engineering ads.

Consistent with the social engineering policy we announced in November, embedded content (like ads) on a web page will be considered social engineering when they either:

• Pretend to act, or look and feel, like a trusted entity — like your own device or browser, or the website itself. 
• Try to trick you into doing something you’d only do for a trusted entity — like sharing a password or calling tech support.

Below are some examples of deceptive content, shown via ads:

This image claims that your software is out-of-date to trick you into clicking “update”. 

This image mimics a dialogue from the FLV software developer -- but it does not actually originate from this developer.

These buttons seem like they will produce content that relate to the site (like a TV show or sports video stream) by mimicking the site’s look and feel. They are often not distinguishable from the rest of the page.

Our fight against unwanted software and social engineering is still just beginning. We'll continue to improve Google's Safe Browsing protection to help more people stay safe online.

Will my site be affected?

If visitors to your web site consistently see social engineering content, Google Safe Browsing may warn users when they visit the site. If your site is flagged for containing social engineering content, you should troubleshoot with Search Console. Check out our social engineering help for webmasters.