Google Online Security Blog

Introducing the Android Ecosystem Security Transparency Report

November 8, 2018

Posted by Jason Woloz and Eugene Liderman, Android Security & Privacy TeamUpdate: We identified a bug that affected how we calculated data from Q3 2018 in the Transparency Report. This bug created inconsistencies between the data in the report and this blog post. The data points in this blog post have been corrected.What's new in Android securityannual Android Security Year in ReviewAndroid Ecosystem Security Transparency ReportTransparency ReportGoogle Play ProtectPotentially Harmful ApplicationsDevices with Potentially Harmful Applications installed by market segment
2017 Year in ReviewDevices with Potentially Harmful Applications installed by Android version
Devices with Potentially Harmful Applications rate by top 10 countries
Year in ReviewDevices with Potentially Harmful Applications rate by top 10 countriesCheck out the report
Android Ecosystem Security Transparency ReportFAQs section of the Transparency Reportblog postvideo

A New Chapter for OSS-Fuzz

November 6, 2018

Posted by Matt Ruhstaller, TPM and Oliver Chang, Software Engineer, Google Security TeamOSS-FuzzGoogle Cloud Platformlaunching9,000manually reportedresolvedPatch Rewards Programideal integrationherereviewOur goal is to admit as many OSS projects as possible and ensure that they are continuously fuzzed.
fuzz target

Announcing some security treats to protect you from attackers’ tricks

October 31, 2018

Posted by Jonathan Skelker, Product ManagerProtecting you before you even sign in Chances are, JavaScript is already enabled in your browser; it helps power lots of the websites people use everyday. But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users (0.1%) choose to keep it off. This might make sense if you are reading static content, but we recommend that you keep Javascript on while signing into your Google Account so we can better protect you. You can read more about how to enable JavaScript here.

Keeping your Google Account secure while you’re signed in
Last year, we launched a major update to the Security Checkup that upgraded it from the same checklist for everyone, to a smarter tool that automatically provides personalized guidance for improving the security of your Google Account.
We’re adding to this advice all the time. Most recently, we introduced better protection against harmful apps based on recommendations from Google Play Protect, as well as the ability to remove your account from any devices you no longer use.

More notifications when you share your account data with apps and sites
It’s really important that you understand the information that has been shared with apps or sites so that we can keep you safe. We already notify you when you’ve granted access to sensitive information — like Gmail data or your Google Contacts — to third-party sites or apps, and in the next few weeks, we’ll expand this to notify you whenever you share any data from your Google Account. You can always see which apps have access to your data in the Security Checkup.

Helping you get back to the beginning if you run into trouble
In the rare event that your account is compromised, our priority is to help get you back to safety as quickly as possible. We’ve introduced a new, step-by-step process within your Google Account that we will automatically trigger if we detect potential unauthorized activity.
We'll help you:

Verify critical security settings to help ensure your account isn’t vulnerable to additional attacks and that someone can’t access it via other means, like a recovery phone number or email address.

Secure your other accounts because your Google Account might be a gateway to accounts on other services and a hijacking can leave those vulnerable as well.

Check financial activity to see if any payment methods connected to your account, like a credit card or Google Pay, were abused.

Review content and files to see if any of your Gmail or Drive data was accessed or mis-used.

Online security can sometimes feel like walking through a haunted house—scary, and you aren't quite sure what may pop up. We are constantly working to strengthen our automatic protections to stop attackers and keep you safe you from the many tricks you may encounter. During Cybersecurity Month, and beyond, we've got your back.

Introducing reCAPTCHA v3: the new way to stop bots

October 29, 2018

Posted by Wei Liu, Google Product Manager[Cross-posted from the Google Webmaster Central Blog]reCAPTCHA v3A frictionless user experience
More Accurate Bot Detection with "Actions"

Fighting bots your waydeveloper site

Google tackles new ad fraud scheme

October 23, 2018

Posted by Per Bjorke, Product Manager, Ad Traffic QualityTechnical DetailTechSnabChrome Cleanup

Android Protected Confirmation: Taking transaction security to the next level

October 19, 2018

Posted by Janis Danisevskis, Information Security Engineer, Android Security[Cross-posted from the Android Developers Blog]

Transaction Authentication NumberAndroidKeyStoreKeystore AttestationWhat's new in Android security
DTMoStDTMoStAndroid Protected Confirmation training article

Building a Titan: Better security through a tiny chip

October 17, 2018

Posted by Nagendra Modadugu and Bill Richardson, Google Device Security Group[Cross-posted from the Android Developers Blog]Made by GoogleKeyword BlogTitan familypost

Storing and enforcing the locks and rollback counters used by Android Verified Boot.

Securely storing secrets and rate-limiting invalid attempts at retrieving them using the Weaver API.

Providing backing for the Android Strongbox Keymaster module, including Trusted User Presence and Protected Confirmation. Titan M has direct electrical connections to the Pixel's side buttons, so a remote attacker can't fake button presses. These features are available to third-party apps, such as FIDO U2F Authentication.

Enforcing factory-reset policies, so that lost or stolen phones can only be restored to operation by the authorized owner.

Ensuring that even Google can't unlock a phone or install firmware updates without the owner's cooperation with Insider Attack Resistance.

RowhammerSpectreMeltdownside channel attacks A closer look at Titan M

Titan (left) and Titan M (right)

Better security through transparency and innovation

Modernizing Transport Security

October 15, 2018

Posted by David Benjamin, Chrome networking*Updated on October 17, 2018 with details about changes in other browsersTLS 1.0TLS 1.2now brokenPCI-DSS compliantdocumentAppleMicrosoftMozilla

TLS 1.2 or later.

An ECDHE- and AEAD-based cipher suite. AEAD-based cipher suites are those using AES-GCM or ChaCha20-Poly1305. ECDHE_RSA_WITH_AES_128_GCM_SHA256 is the recommended option for most sites.

The server signature should use SHA-2. Note this is not the signature in the certificate, made by the CA. Rather, it is the signature made by the server itself, using its private key.

The older options—CBC-mode cipher suites, RSA-encryption key exchange, and SHA-1 online signatures—all have known cryptographic flaws. Each has been removed in the newly-published TLS 1.3, which is supported in Chrome 70. We retain them at prior versions for compatibility with legacy servers, but we will be evaluating them over time for eventual deprecation.

None of these changes require obtaining a new certificate. Additionally, they are backwards-compatible. Where necessary, servers may enable both modern and legacy options, to continue to support legacy clients. Note, however, such support may carry security risks. (For example, see the DROWN, FREAK, and ROBOT attacks.)

Over the coming Chrome releases, we will improve the DevTools Security Panel to point out deviations from these settings, and suggest improvements to the site’s configuration.

Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 until January 2021.

Google and Android have your back by protecting your backups

October 12, 2018

Posted by Troy Kensinger, Technical Program Manager, Android Security and PrivacyAndroid’s Backup ServiceGoogle Cloud’s Titan TechnologyTitan security chipNCC Group’shereWe want to acknowledge contributions from Shabsi Walfish, Software Engineering Lead, Identity and Authentication to this effort

Control Flow Integrity in the Android kernel

October 10, 2018

Posted by Sami Tolvanen, Staff Software Engineer, Android Security & Privacy[Cross-posted from the Android Developers Blog]hardening the kernelcompiler-based security mitigationsControl Flow Integrity (CFI)CFI support available in Android kernel versions 4.9 and 4.14 Protecting against code reuse attacks

Figure 1. In an Android device kernel, LLVM's CFI limits 55% of indirect calls to at most 5 possible targets and 80% to at most 20 targets. Gaining full program visibility with Link Time Optimization (LTO)

Figure 2. A simplified overview of how LTO works in the kernel. All LLVM bitcode is combined, optimized, and generated into native code at link time.4.94.14LDFLAGS += -plugin-opt=-inline-threshold=0 \ -plugin-opt=-unroll-threshold=0 Implementing CFI in the Linux kernelLLVM's CFI4.94.14cross-DSO CFI

Figure 3. An example of a cross-DSO CFI check injected into an arm64 kernel. Type information is passed in X0 and the target address to validate in X1. Enabling kernel CFI for an Android deviceclangbinutilsCONFIG_LTO_CLANG=y CONFIG_CFI_CLANG=yCFI failure (target: [<fffffff3e83d4d80>] my_target_function+0x0/0xd80): ------------[ cut here ]------------ kernel BUG at kernel/cfi.c:32! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP … Call trace: … [<ffffff8752d00084>] handle_cfi_failure+0x20/0x28 [<ffffff8752d00268>] my_buggy_function+0x0/0x10 … Figure 4. An example of a kernel panic caused by a CFI failure.static int __nocfi address_space_conflict() { void (*fn)(void); … /* branching to a physical address trips CFI w/o __nocfi */ fn = (void *)__pa_symbol(function_name); cpu_install_idmap(); fn(); cpu_uninstall_idmap(); … } Figure 5. An example of fixing a CFI failure caused by an address space conflict.KASAN ConclusionShadow Call Stack

Security Blog

Introducing the Android Ecosystem Security Transparency Report

A New Chapter for OSS-Fuzz

Announcing some security treats to protect you from attackers’ tricks

Introducing reCAPTCHA v3: the new way to stop bots

Google tackles new ad fraud scheme

Android Protected Confirmation: Taking transaction security to the next level

Building a Titan: Better security through a tiny chip

Modernizing Transport Security

Google and Android have your back by protecting your backups

Control Flow Integrity in the Android kernel

Labels

Archive

Feed

Company-wide

Products

Developers