https://www.whatsupup.com/domain/security.googleblog.com/ Recent content in security.googleblog.com on see the changes en-us Wed, 18 May 2022 16:22:14 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220518-162214/ Wed, 18 May 2022 16:22:14 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220518-162214/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/05/privileged-pod-escalations-in.html">Privileged pod escalations in Kubernetes and GKE</a><br></p> <hr> Posted by GKE and Anthos Platform Security Teams<br> At the KubeCon EU 2022 conference in Valencia, security researchers from Palo Alto Networks presented research findings on “trampoline pods”—pods with an elevated set of privileges required to do their job, but that could conceivably be used as a jumping off point to gain escalated privileges. The research mentions GKE, including how developers should look at the privileged pod problem today, what the GKE team is doing to minimize the use of privileged pods, and actions GKE users can take to protect their clusters.<br> Privileged pods within the context of GKE security While privileged pods can pose a security issue, it’s important to look at them within the overall context of GKE security. To use a privileged pod as a “trampoline” in GKE, there is a major prerequisite – the attacker has to first execute a successful application compromise and container breakout attack. Because the use of privileged pods in an attack requires a first step such as a container breakout to be effective, let’s look at two areas:<br> features of GKE you can use to reduce the likelihood of a container breakout<br> steps the GKE team is taking to minimize the use of privileged pods and the privileges needed in them.<br> Reducing container breakouts There are a number of features in GKE along with some best practices that you can use to reduce the likelihood of a container breakout:<br> Use <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods">GKE Sandbox</a> to strengthen the container security boundary. Over the last few months, GKE Sandbox has protected containers running it against several newly discovered <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins">Linux kernel breakout CVEs</a> .<br> Adopt <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview">GKE Autopilot</a> for new clusters. Autopilot clusters have default policies that prevent host access through mechanisms like host path volumes and host network. The container runtime default seccomp profile is also <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#security-limitations">enabled by default on Autopilot</a> which has prevented <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2022-006">several</a> <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2022-002">breakouts</a> .<br> Subscribe to <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels">GKE Release Channels</a> and use autoupgrade to keep nodes patched automatically against kernel vulnerabilities.<br> Run <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/node-images#cos">Google’s Container Optimized OS</a> , the minimal and <a rel="noreferrer" target="_blank" href="https://cloud.google.com/container-optimized-os/docs/concepts/security">hardened</a> container optimized OS that makes much of the disk read-only.<br> Incorporate <a rel="noreferrer" target="_blank" href="https://cloud.google.com/binary-authorization">binary authorization</a> into your SDLC to require that containers admitted into the cluster are from trusted build systems and up-to-date on patching.<br> Use <a rel="noreferrer" target="_blank" href="https://cloud.google.com/security-command-center/docs/concepts-container-threat-detection-overview">Secure Command Center’s Container Threat Detection</a> or supported third-party tools to detect the most common runtime attacks.<br> More information can be found in the <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster">GKE Hardening Guide</a> .<br> How GKE is reducing the use of privileged pods. While it’s not uncommon for customers to install privileged pods into their clusters, GKE works to minimize the privilege levels held by our system components, especially those that are enabled by default. However, there are limits as to how many privileges can be removed from certain features. For example, Anthos Config Management requires permissions to modify most Kubernetes objects to be able to create and manage those objects. Some other privileges are baked into the system, such as those held by Kubelet. Previously, we worked with the Kubernetes community to build the <a rel="noreferrer" target="_blank" href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction">Node Restriction</a> and <a rel="noreferrer" target="_blank" href="https://kubernetes.io/docs/reference/access-authn-authz/node/">Node Authorizer</a> features to limit Kubelet's access to highly sensitive objects, such as secrets, adding protection against an attacker with access to the Kubelet credentials. More recently, we have taken steps to reduce the number of privileged pods across GKE and have added additional documentation on privileges used in system pods as well as information on how to improve pod isolation. Below are the steps we’ve taken:<br> We have added <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#restrict_self_modify">an admission controller to GKE Autopilot and GKE Standard (on by default) and GKE/Anthos (opt-in)</a> that stops attempts to run as a more privileged service account, which blocks a method of escalating privileges using privileged pods.<br> We created a permission scanning tool that identifies pods that have privileges that could be used for escalation, and we used that tool to perform an audit across GKE and Anthos.<br> The permission scanning tool is now integrated into our standard code review and testing processes to reduce the risk of introducing privileged pods into the system. As mentioned earlier, some features require privileges to perform their function.<br> We are using the audit results to reduce permissions available to pods. For example, we removed “update nodes and pods” permissions from anetd in GKE.<br> Where privileged pods are required for the operation of a feature, we’ve added additional documentation to illustrate that fact.<br> We added <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/how-to/isolate-workloads-dedicated-nodes">documentation</a> that outlines how to isolate GKE-managed workloads in dedicated node pools when you’re unable to use GKE Sandbox to reduce the risk of privilege escalation attacks.<br> In addition to the measures above, we recommend users take advantage of tools that can scan RBAC settings to detect overprivileged pods used in their applications. As part of their presentation, the Palo Alto researchers announced an open source tool, called <a rel="noreferrer" target="_blank" href="https://github.com/PaloAltoNetworks/rbac-police">rbac-police</a> , that can be used for the task. So, while it only takes a single overprivileged workload to trampoline to the cluster, there are a number of actions you can take to minimize the likelihood of the prerequisite container breakout and the number of privileges used by a pod.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220511-203221/ Wed, 11 May 2022 20:32:21 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220511-203221/ Last month, we also started rolling out <a rel="noreferrer" target="_blank" href="https://blog.google/products/google-play/data-safety/">a new Data safety section</a> in Google Play to help you understand how apps plan to collect, share, and protect your data, before you install it. To instill even more trust in Play apps, we're enabling developers to have their apps independently validated against <a rel="noreferrer" target="_blank" href="https://github.com/OWASP/owasp-masvs">OWASP’s MASVS</a> , a globally recognized standard for mobile app security.<br> Posted by Daniel Margolis, Software Engineer, Google Account Security Team Every year, security technologies improve: <a rel="noreferrer" target="_blank" href="https://www.google.com/chrome/security/">browsers get better</a> , <a rel="noreferrer" target="_blank" href="https://transparencyreport.google.com/https/overview?hl=en">encryption becomes ubiquitous on the Web</a> , authentication becomes stronger. But phishing persistently remains a threat (as shown by <a rel="noreferrer" target="_blank" href="https://www.techrepublic.com/article/phishing-attack-spoofs-us-department-of-labor-to-steal-account-credentials/">a recent phishing attack on the U.S. Department of Labor</a> ) because users retain the ability to log into their online accounts, often with a simple password, from anywhere in the world. It’s why today <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/io-safer-with-google/">at I/O we announced</a> new ways we’re reducing the risks of phishing by: scaling phishing protections to Google Docs, Sheets and Slides, continuing to auto enroll people in 2-Step Verification and more. This blog will deep dive into the method of phishing and how it has evolved today. As phishing adoption has grown, multi-factor authentication has become a particular focus for attackers. In some cases, attackers phish SMS codes directly, by following a legitimate "one-time passcode" (triggered by the attacker trying to log into the victim's account) with a spoofed message asking the victim to "reply back with the code you just received.”<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220511-192743/ Wed, 11 May 2022 19:27:43 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220511-192743/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/05/io-2022-android-13-security-and-privacy.html">I/O 2022: Android 13 security and privacy (and more!)</a><br></p> <hr> Posted by Eugene Liderman and Sara N-Marandi, Android Security and Privacy Team<br> Every year at I/O we share the latest on privacy and security features on Android. But we know some users like to go a level deeper in understanding how we’re making the latest release safer, and more private, while continuing to offer a seamless experience. So let’s dig into the tools we’re building to better secure your data, enhance your privacy and increase trust in the apps and experiences on your devices.<br> Low latency, frictionless security<br> Regardless of whether a smartphone is used for consumer or enterprise purposes, attestation is a key underpinning to ensure the integrity of the device and apps running on the device. Fundamentally, key attestation lets a developer bind a secret or designate data to a device. This is a strong assertion: "same user, same device" as long as the key is available, a cryptographic assertion of integrity can be made.<br> With Android 13 we have migrated to a new model for the provisioning of attestation keys to Android devices which is known as Remote Key Provisioning (RKP). This new approach will strengthen device security by eliminating factory provisioning errors and providing key vulnerability recovery by moving to an architecture where Google takes more responsibility in the certificate management lifecycle for these attestation keys. You can learn more about RKP <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2022/03/upgrading-android-attestation-remote.html">here</a> .<br> We’re also making even more modules updatable directly through <a rel="noreferrer" target="_blank" href="https://support.google.com/product-documentation/answer/11462338">Google Play System Updates</a> so we can automatically upgrade more system components and fix bugs, seamlessly, without you having to worry about it. We now have more than 30 components in Android that can be automatically updated through Google Play, including new modules in Android 13 for Bluetooth and ultra-wideband (UWB).<br> Last year we <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/04/rust-in-android-platform.html">talked about</a> how the majority of vulnerabilities in major operating systems are caused by undefined behavior in programming languages like C/C++. Rust is an alternative language that provides the efficiency and flexibility required in advanced systems programming (OS, networking) but Rust comes with the added boost of memory safety. We are happy to report that Rust is being adopted in security critical parts of Android, such as our key management components and networking stacks.<br> Hardening the platform doesn’t just stop with continual improvements with memory safety and expansion of anti-exploitation techniques. It also includes hardening our API surfaces to provide a more secure experience to our end users.<br> In Android 13 we implemented numerous enhancements to help mitigate potential vulnerabilities that app developers may inadvertently introduce. This includes making <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/features#runtime-receivers">runtime receivers safer</a> by allowing developers to specify whether a particular broadcast receiver in their app should be exported and visible to other apps on the device. On top of this, <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/behavior-changes-13#intent-filters">intent filters block non-matching intents</a> which further hardens the app and its components.<br> For enterprise customers who need to meet certain security certification requirements, we’ve updated our security logging reporting to add more coverage and consolidate security logs in one location. This is helpful for companies that need to meet standards like Common Criteria and is useful for partners such as management solutions providers who can review all security-related logs in one place.<br> Privacy on your terms<br> Android 13 brings developers more ways to build privacy-centric apps. Apps can now implement a new Photo picker that allows the user to select <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/features/photopicker">the exact photos or videos</a> they want to share without having to give another app access to their media library.<br> With Android 13, we’re also reducing the number of apps that require your location to function using the nearby devices permission <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2021/05/android-security-and-privacy-recap.html">introduced last year</a> . For example, you won’t have to <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/features/nearby-wifi-devices-permission">turn on location to enable Wi-fi</a> for certain apps and situations. We’ve also <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/behavior-changes-13#granular-media-permissions">changed</a> how storage works, requiring developers to ask for separate permissions to access audio, image and video files.<br> Previously, we’ve limited apps from accessing your clipboard in the background and alerted you when an app accessed it. With Android 13, we’re automatically deleting your clipboard history after a short period so apps are blocked from seeing old copied information.<br> In Android 11, we began <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/11/privacy/permissions#auto-reset">automatically resetting permissions</a> for apps you haven’t used for an extended period of time, and have since <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2021/09/making-permissions-auto-reset-available.html">expanded the feature</a> to devices running Android 6 and above. Since then, we’ve automatically reset over 5 billion permissions.<br> In Android 13, app makers can go above and beyond in <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/features#developer-downgradable-permissions">removing permissions</a> even more proactively on behalf of their users. Developers will be able to provide even more privacy by reducing the time their apps have access to unneeded permissions.<br> Finally, we know notifications are critical for many apps but are not always of equal importance to users. In Android 13, you’ll have more control over which apps you would like to get alerts from, as new apps on your device are <a rel="noreferrer" target="_blank" href="https://developer.android.com/about/versions/13/changes/notification-permission">required to ask you for permission</a> by default before they can send you notifications.<br> Apps you can trust<br> Most app developers build their apps using a variety of software development kits (SDKs) that bundle in pre-packaged functionality. While SDKs provide amazing functionality, app developers typically have little visibility or control over the SDK code or insight into their performance.<br> We’re working with developers to make their apps more secure with a new <a rel="noreferrer" target="_blank" href="https://goo.gle/play-sdk">Google Play SDK Index</a> that helps them see SDK safety and reliability signals before they build the code into their apps. This ensures we're helping everyone build a more secure and private app ecosystem.<br> Last month, we also started rolling out <a rel="noreferrer" target="_blank" href="https://blog.google/products/google-play/data-safety/">a new Data safety section</a> in Google Play to help you understand how apps plan to collect, share, and protect your data, before you install it. To instill even more trust in Play apps, we're enabling developers to have their apps independently validated against <a rel="noreferrer" target="_blank" href="https://owasp.org/www-project-mobile-security-testing-guide/">OWASP’s MASVS</a> , a globally recognized standard for mobile security.<br> We’re working with a small group of developers and authorized lab partners to evolve the <a rel="noreferrer" target="_blank" href="https://appdefensealliance.dev/masa">program</a> . Developers who have completed this independent validation can showcase this on their Data safety section.<br> Additional mobile security and safety<br> Just like our anti-malware protection Google Play, which now scans 125 billion apps a day, we believe spam and phishing detection should be built in. We’re proud to announce that in a recent <a rel="noreferrer" target="_blank" href="https://omdia.tech.informa.com/commissioned-research/articles/omdia-consumer-mobile-security-scorecard">analyst report</a> , Messages was the highest rated built-in messaging app for anti-phishing and scams protection.<br> Messages is now also helping to protect you against 1.5 billion spam messages per month, so you can avoid both annoying texts and attempts to access your data. These phishing attempts are increasingly how bad actors are trying to get your information, by getting you to click on a link or download an app, so we are always looking for ways to offer another line of defense.<br> Last year, we introduced <a rel="noreferrer" target="_blank" href="https://www.android.com/google-features-on-android/summer-2021/#summer-2021-end-to-end-contents">end-to-end encryption in Messages</a> to provide more security for your mobile conversations. Later this year, we’ll launch end-to-end encryption group conversations in beta to ensure your personal messages get even more protection.<br> As with a lot of features we build, we try to do it in an open and transparent way. In Android 11 we announced a new <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/10/privacy-preserving-features-in-mobile.html">platform feature</a> that was backed by an <a rel="noreferrer" target="_blank" href="https://www.iso.org/standard/69084.html">ISO standard</a> to enable the use of digital IDs on a smartphone in a privacy-preserving way. When you hand over your plastic license (or other credential) to someone for verification it’s all or nothing which means they have access to your full name, date of birth, address, and other personally identifiable information (PII). The mobile version of this allows for much more fine-grained control where the end user and/or app can select exactly what to share with the verifier. In addition, the verifier must declare whether they intend to retain the data returned. In addition, you can present certain details of your credentials, such as age, without revealing your identity.<br> Over the last two Android releases we have been improving this API and making it easier for third-party organizations to leverage it for various digital identity use cases, such as driver’s licenses, student IDs, or corporate badges. We’re now announcing that Google Wallet uses Android <a rel="noreferrer" target="_blank" href="https://source.android.com/security/features/identity-credentials">Identity Credential</a> to support digital IDs and driver’s licenses. We’re working with states in the US and governments around the world to bring digital IDs to Wallet later this year. You can learn more about all of the new enhancements in Google Wallet <a rel="noreferrer" target="_blank" href="https://blog.google/products/android/ask-a-techspert-google-wallet">here</a> .<br> Protected by Android<br> We don’t think your security and privacy should be hard to understand and control. Later this year, we’ll begin rolling out a new destination in settings on Android 13 devices that puts all your device security and data privacy front and center.<br> The new Security & Privacy settings page will give you a simple, color-coded way to understand your safety status and will offer clear and actionable guidance to improve it. The page will be anchored by new action cards that notify you of critical steps you should take to address any safety risks. In addition to notifications to warn you about issues, we’ll also provide timely recommendations on how to enhance your privacy.<br> We know that to feel safe and in control of your data, you need to have a secure foundation you can count on. Because if your device isn’t secure, it’s not private either. We’re working hard to make sure you’re always protected by Android. Learn more about these protections on our <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/android.com/safety">website</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220511-180603/ Wed, 11 May 2022 18:06:03 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220511-180603/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/05/taking-on-next-generation-of-phishing.html">Taking on the Next Generation of Phishing Scams</a><br></p> <hr> Posted by Daniel Margolis, Senior Software Engineer, Google Account Security Team Every year, security technologies improve: <a rel="noreferrer" target="_blank" href="https://www.google.com/chrome/security/">browsers get better</a> , <a rel="noreferrer" target="_blank" href="https://transparencyreport.google.com/https/overview?hl=en">encryption becomes ubiquitous on the Web</a> , authentication becomes stronger. But phishing persistently remains a threat (as shown by <a rel="noreferrer" target="_blank" href="https://www.techrepublic.com/article/phishing-attack-spoofs-us-department-of-labor-to-steal-account-credentials/">a recent phishing attack on the U.S. Department of Labor</a> ) because users retain the ability to log into their online accounts, often with a simple password, from anywhere in the world. It’s why today <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/io-safer-with-google/">at I/O we announced</a> new ways we’re reducing the risks of phishing by: scaling phishing protections to Google Docs, Sheets and Slides, continuing to auto enroll people in 2-Step Verification and more. This blog will deep dive into the method of phishing and how it has evolved today. As phishing adoption has grown, multi-factor authentication has become a particular focus for attackers. In some cases, attackers phish SMS codes directly, by following a legitimate "one-time passcode" (triggered by the attacker trying to log into the victim's account) with a spoofed message asking the victim to "reply back with the code you just received.”<br> Left: legitimate Google SMS verification. Right: spoofed message asking victim to share verification code.<br> In other cases, attackers have leveraged more sophisticated dynamic phishing pages to conduct relay attacks. In these attacks, a user thinks they're logging into the intended site, just as in a standard phishing attack. But instead of deploying a simple static phishing page that saves the victim's email and password when the victim tries to login, the phisher has deployed a web service that logs into the actual website at the same time the user is falling for the phishing page. The simplest approach is an almost off-the-shelf "reverse proxy" which acts as a "person in the middle", forwarding the victim's inputs to the legitimate page and sending the response from the legitimate page back to the victim's browser.<br> These attacks are especially challenging to prevent because additional authentication challenges shown to the attacker—like a prompt for an SMS code—are also relayed to the victim, and the victim's response is in turn relayed back to the real website. In this way, the attacker can count on their victim to solve any authentication challenge presented. Traditional multi-factor authentication with PIN codes can only do so much against these attacks, and authentication with smartphone approvals via a prompt — while more secure against SIM-swap attacks — is still vulnerable to this sort of real-time interception.<br> The Solution Space Over the past year, we've <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/making-sign-safer-and-more-convenient/">started to automatically enable device-based two-factor authentication</a> for our users. This authentication not only helps protect against traditional password compromise but, with technology improvements, we can also use it to help defend against these more sophisticated forms of phishing. Taking a broad view, most efforts to protect and defend against phishing fall into the following categories:<br> <a rel="noreferrer" target="_blank" href="https://dev.chromium.org/Home/chromium-security/enamel">Browser UI improvements</a> to help users identify authentic websites.<br> <a rel="noreferrer" target="_blank" href="https://support.google.com/accounts/answer/6208650?hl=en">Password managers</a> that can validate the identity of the web page before logging in.<br> Phishing detection, both in <a rel="noreferrer" target="_blank" href="https://safety.google/gmail/">email</a> —the most common delivery channel—and in the <a rel="noreferrer" target="_blank" href="https://safebrowsing.google.com/">browser</a> itself, to warn users about suspicious web pages.<br> Preventing the person-in-the-middle attacks mentioned above by <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html">preventing automated login attempts</a> .<br> Phishing-resistant authentication using <a rel="noreferrer" target="_blank" href="https://fidoalliance.org/how-fido-works/">FIDO</a> with security keys or a Bluetooth connection to your phone.<br> Hardening the Google Prompt challenge to help users identify suspicious sign-in attempts, or to ask them to take additional steps that can defeat phishing (like navigating to a new web address, or to join the same wireless network as the computer they're logging into).<br> Expanding phishing-resistant authentication to more users Over the last decade we’ve been working hard with a number of industry partners on expanding phishing-resistant authentication mechanisms, as part of <a rel="noreferrer" target="_blank" href="https://fidoalliance.org/">FIDO Alliance</a> . Through these efforts we introduced physical FIDO security keys, such as the <a rel="noreferrer" target="_blank" href="https://store.google.com/product/titan_security_key">Titan Security Key</a> , which prevent phishing by verifying the identity of the website you're logging into. (This verification protects against the "person-in-the-middle" phishing described above.) Recently, we <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/">announced</a> a major milestone with the FIDO Alliance, Apple and Microsoft by expanding our support for the FIDO Sign-in standards, helping to launch us into a truly passwordless, phishing-resistant future. Even though security keys work great, we don't expect everyone to add one to their keyring.<br> Instead, to make this level of security more accessible, we're building it into mobile phones. Unlike physical FIDO security keys that need to be connected to your device via USB, we use Bluetooth to ensure your phone is close to the device you're logging into. Like physical security keys, this helps prevent a distant attacker from tricking you into approving a sign-in on their browser, giving us an added layer of security against the kind of "person in the middle" attacks that can still work against SMS or Google Prompt. ( <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/security-myth-busting-and-spring-cleaning/">But don't worry</a> : this doesn't allow computers within Bluetooth range to login as you—it only grants that approval to the computer you're logging into. And we only use this to verify that your phone is near the device you're logging into, so you only need to have Bluetooth on during login.) Over the next couple of months we’ll be rolling out this technology in more places, which you might notice as a request for you to enable Bluetooth while logging in, so we can perform this additional security check. If you've signed into your Google account on your Android phone, we can enroll your phone automatically—just like with Google Prompt—allowing us to give this added layer of security to many of our users without the need for any additional setup. But unfortunately this secure login doesn't work everywhere—for example, when logging into a computer that doesn't support Bluetooth, or a browser that doesn't support security keys. That's why, if we are to offer phishing-resistant security to everyone, we have to offer backups when security keys aren't available—and those backups must also be secure enough to prevent attackers from taking advantage of them.<br> Hardening existing challenges against phishin g Over the past few months, we've started experimenting with making our traditional Google Prompt challenges more phishing resistant. We already use different challenge experiences depending on the situation—for example, sometimes we ask the user to match a PIN code with what they're seeing on the screen in addition to clicking "allow" or "deny". This can help prevent static phishing pages from tricking you into approving a challenge. We've also begun experimenting with more involved challenges for higher-risk situations, including more prominent warnings when we see you logging in from a computer that we think might belong to a phisher, or asking you to join your phone to the same Wi-Fi network as the computer you're logging into so we can be sure the two are near each other. Similar to our use of Bluetooth for Security Keys, this prevents an attacker from tricking you into logging into a "person-in-the-middle" phishing page.<br> Bringing it all together<br> Of course, while all of these options dramatically increase account security, we also know that they can be a challenge for some of our users, which is why we're rolling them out gradually, as part of a risk-based approach that also focuses on usability. If we think an account is at a higher risk, or if we see abnormal behavior, we're more likely to use these additional security measures. Over time, as FIDO2 authentication becomes more widely available, we expect to be able to make it the default for many of our users, and to rely on stronger versions of our existing challenges like those described above to provide secure fallbacks. All these new tools in our toolbox—detecting browser automation to prevent "person in the middle" attacks, warning users in Chrome and Gmail, making the Google Prompt more secure, and automatically enabling Android phones as easy-to-use Security Keys—work together to allow us to better protect our users against phishing. Phishing attacks have long been seen as a persistent threat, but these recent developments give us the ability to really move the needle and help more of our users stay safer online.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220428-200915/ Thu, 28 Apr 2022 20:09:14 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220428-200915/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/the-package-analysis-project-scalable.html">The Package Analysis Project: Scalable detection of malicious open source packages</a><br></p> <hr> Posted by Caleb Brown, Open Source Security Team<br> Despite open source software’s essential role in all software built today, it’s far too easy for bad actors to circulate malicious packages that attack the systems and users running that software. Unlike mobile app stores that can scan for and reject malicious contributions, package repositories have limited resources to review the thousands of daily updates and must maintain an open model where anyone can freely contribute. As a result, malicious packages like <a rel="noreferrer" target="_blank" href="https://github.com/advisories/GHSA-pjwm-rvh2-c87w">ua-parser-js</a> , and <a rel="noreferrer" target="_blank" href="https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/">node-ipc</a> are regularly uploaded to popular repositories despite their best efforts, with sometimes devastating consequences for users. Google, a member of the <a rel="noreferrer" target="_blank" href="https://openssf.org/">Open Source Security Foundation</a> (OpenSSF), is proud to support the OpenSSF’s <a rel="noreferrer" target="_blank" href="https://openssf.org/blog/2022/04/28/introducing-package-analysis-scanning-open-source-packages-for-malicious-behavior">Package Analysis project,</a> which is a welcome step toward helping secure the open source packages we all depend on. The Package Analysis program performs dynamic analysis of all packages uploaded to popular open source repositories and catalogs the results in a BigQuery table. By detecting malicious activities and alerting consumers to suspicious behavior before they select packages, this program contributes to a more secure software supply chain and greater trust in open source software. The program also gives insight into the types of malicious packages that are most common at any given time, which can guide decisions about how to better protect the ecosystem. To better understand how the Package Analysis program is contributing to supply chain security, we analyzed the nearly 200 malicious packages it captured over a one-month period. Here’s what we discovered:<br> Results<br> All signals collected are published in our <a rel="noreferrer" target="_blank" href="https://console.cloud.google.com/bigquery?d=packages&p=ossf-malware-analysis&t=analysis&page=table">BigQuery table</a> . Using simple queries on this table, we found around 200 meaningful results from the packages uploaded to NPM and PyPI in a period of just over a month. Here are some notable examples, with <a rel="noreferrer" target="_blank" href="https://github.com/ossf/package-analysis/blob/main/docs/case_studies.md">more available in the repository</a> .<br> PyPI: discordcmd<br> This Python package will attack the desktop client for Discord on Windows. It was found by spotting the unusual requests to raw.githubusercontent.com, Discord API, and ipinfo.io. First, it downloaded a backdoor from GitHub and installed it into the Discord electron client.<br> Next, it looked through various local databases for the user's Discord token.<br> Finally, it grabbed the data associated with the token from the Discord API and exfiltrated it back to a Discord server controlled by the attacker.<br> NPM: @roku-web-core/ajax<br> During install, this NPM package exfiltrates details of the machine it is running on and then opens a reverse shell, allowing the remote execution of commands.<br> This package was discovered from its requests to an attacker-controlled address.<br> Dependency Confusion / Typosquatting<br> The vast majority of the malicious packages we detected are dependency confusion and <a rel="noreferrer" target="_blank" href="https://www.darkreading.com/vulnerabilities-threats/beware-the-package-typosquatting-supply-chain-attack">typosquatting attacks</a> . The packages we found usually contain a simple script that runs during an install and calls home with a few details about the host. These packages are most likely the work of security researchers looking for bug bounties, since most are not exfiltrating meaningful data except the name of the machine or a username, and they make no attempt to disguise their behavior. These dependency confusion attacks were discovered through the domains they used, such as burpcollaborator.net, pipedream.com, interact.sh, which are commonly used for reporting back attacks. The same domains appear across unrelated packages and have no apparent connection to the packages themselves. Many packages also used unusual version numbers that were high (e.g. v5.0.0, v99.10.9) for a package with no previous versions.<br> Conclusions<br> The short time frame and low sophistication needed for finding the results above underscore the challenge facing open source package repositories. While many of the results above were likely the work of security researchers, any one of these packages could have done far more to hurt the unfortunate victims who installed them. These results show the clear need for more investment in vetting packages being published in order to keep users safe. This is a growing space, and having an open standard for reporting would help centralize analysis results and offer consumers a trusted place to assess the packages they’re considering using. Creating an open standard should also foster healthy competition, promote integration, and raise the overall security of open source packages.<br> Over time we hope that the Package Analysis program will offer comprehensive knowledge about the behavior and capabilities of packages across open source software, and help guide the future efforts needed to make the ecosystem more secure for everyone. To get involved, please check out the <a rel="noreferrer" target="_blank" href="https://github.com/ossf/package-analysis">GitHub Project</a> and <a rel="noreferrer" target="_blank" href="https://github.com/ossf/package-analysis/milestones">Milestones</a> for opportunities to contribute.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220427-162015/ Wed, 27 Apr 2022 16:20:15 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220427-162015/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/how-we-fought-bad-apps-and-developers.html">How we fought bad apps and developers in 2021</a><br></p> <hr> Posted by Steve Kafka and Khawaja Shams, Android Security and Privacy Team<br> Providing a safe experience to billions of users continues to be one of the <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2022/03/privacy-and-security-direction.html">highest priorities</a> for Google Play. Last year we introduced multiple privacy focused features, enhanced our protections against bad apps and developers, and improved <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Software_development_kit">SDK</a> data safety. In addition, Google Play Protect continues to scan billions of installed apps each day across billions of devices to keep people safe from malware and unwanted software.<br> We continue to enhance our machine learning systems and review processes, and in 2021 we blocked 1.2 million policy violating apps from being published on Google Play, preventing billions of harmful installations. We also continued in our efforts to combat malicious and spammy developers, banning 190k bad accounts in 2021. In addition, we have closed around 500k developer accounts that are inactive or abandoned.<br> In May we <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2021/05/new-safety-section-in-google-play-will.html">announced</a> our new Data safety section for Google Play where developers will be required to give users deeper insight into the privacy and security practices of the apps they download, and provide transparency into the data the app may collect and why. The Data safety section <a rel="noreferrer" target="_blank" href="https://blog.google/products/google-play/data-safety/">launched</a> this week, and developers are required to complete this section for their apps by July 20th.<br> We’ve also invested in making life easier for our developers. We added the <a rel="noreferrer" target="_blank" href="https://play.google.com/console/about/policystatus/">Policy and Programs</a> section to Google Play Console to help developers manage all their app compliance issues in one central location. This includes the ability to appeal a decision and <a rel="noreferrer" target="_blank" href="https://support.google.com/googleplay/android-developer/answer/9842754?hl=en">track its status</a> from this page.<br> In addition, we continued to partner with SDK developers to improve app safety, limit how user data is shared, and <a rel="noreferrer" target="_blank" href="https://support.google.com/googleplay/android-developer/answer/10358880">improve lines of communication with app developers</a> . SDKs provide functionality for app developers, but it can sometimes be tricky to know when an SDK is safe to use. Last year, we engaged with SDK developers to build a safer Android and Google Play ecosystem. As a result of this work, SDK developers have improved the safety of SDKs used by hundreds of thousands of apps impacting billions of users. This remains a huge investment area for our team, and we will continue in our efforts to make SDKs safer across the ecosystem.<br> Limiting access<br> The best way to ensure users' data stays safe is to limit access to it in the first place.<br> As a result of new platform protections and <a rel="noreferrer" target="_blank" href="https://support.google.com/googleplay/android-developer/answer/10467955">policies</a> , developer collaboration and education, 98% of apps migrating to Android 11 or higher have reduced their access to sensitive APIs and user data. We've also significantly reduced the unnecessary, dangerous, or disallowed use of <a rel="noreferrer" target="_blank" href="https://support.google.com/googleplay/android-developer/answer/10964491?hl=en#:~:text=Google%20Play%20permits%20the%20use,that%20they%20are%20accessibility%20tools.">Accessibility APIs</a> in apps migrating to Android 12, while preserving the functionality of legitimate use cases.<br> We also continued in our commitment to make Android a great place for families. Last year we disallowed the collection of Advertising ID (AAID) and other device identifiers from all users in apps solely targeting children, and gave all users the ability to delete their Advertising ID entirely, regardless of the app.<br> Pixel enhancements<br> For Pixel users, we had even more great features to help keep you safe. Our new <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/10/pixel-6-setting-new-standard-for-mobile.html">Security hub</a> helps protect your phone, apps, Google Account, and passwords by giving you a central view of your device’s current configuration. Security hub also provides recommendations to improve your security, helping you decide what settings best meet your needs.<br> In addition, Pixels now use new machine learning models that improve the detection of malware in Google Play Protect. The detection runs on your Pixel, and uses a privacy preserving technology called federated analytics to discover bad apps.<br> Our global teams are dedicated to keeping our billions of users safe, and look forward to many exciting announcements in 2022.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220416-001334/ Sat, 16 Apr 2022 00:13:34 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220416-001334/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/how-to-slsa-part-3-putting-it-all.html">How to SLSA Part 3 - Putting it all together</a><br></p> <hr> Posted by Tom Hennen, software engineer, BCID & GOSST<br> In our last two posts ( <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/how-to-slsa-part-1-basics.html">1</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/how-to-slsa-part-2-details.html">2</a> ) we introduced a fictional example of Squirrel, Oppy, and Acme learning to SLSA and covered the basics and details of how they’d use SLSA for their organizations. Today we’ll close out the series by exploring how each organization pulls together the various solutions into a heterogeneous supply chain. As a reminder, Acme is trying to produce a container image that contains three artifacts:<br> The Squirrel package ‘foo’<br> The Oppy package ‘baz’<br> A custom executable, ‘bar’, written by Acme employees.<br> The process starts with ‘foo’ package authors triggering a build using GitHub Actions. This results in a new version of ‘foo’ (an artifact with hash ‘abc’) being pushed to the Squirrel repo along with its SLSA provenance (signed by Fulcio) and <a rel="noreferrer" target="_blank" href="https://github.com/in-toto/attestation/issues/47">source attestation</a> . When Squirrel gets this push request it verifies the artifact against the specific policy for ‘foo’ which checks that it was built by GitHub Actions from the expected source repository. After the artifact passes the policy check a VSA is created and the new package, its original SLSA provenance, and the VSA are made public in the Squirrel repo, available to all users of package ‘foo’. Next the maintainers of the Oppy ‘baz’ package trigger a new build using the Oppy Autobuilder. This results in a new version of ‘baz’ (an artifact with hash ‘def’) being pushed to a public Oppy repo with the SLSA provenance (signed by their org-specific keys) published to Rekor. When the repo gets the push request it makes the artifact available to the public. The repo does not perform any verification at this time. An Acme employee then makes a change to their Dockerfile, sending it for review by their co-worker, who approves the change and merges the PR. This then causes the Acme builder to trigger a build. During this build:<br> bar is compiled from source code stored in the same source repo as the Dockerfile.<br> acorn install downloads ‘foo’ from the Squirrel repo, verifying the VSA, and recording the use of acorn://foo@abc and its VSA in the build.<br> acme_oppy_get install (a custom script made by Acme) downloads the latest version of the Oppy ‘baz’ package and queries its SLSA provenance and other attestations from Rekor. It then performs a full verification checking that it was built by ‘https://oppy.example/slsa/builder/v1’ and the publicized key. Once verification is complete it records the use of oppy://baz@def and the associated attestations in the build.<br> The build process assembles the SLSA provenance for the container by:<br> Recording the Acme git repo the bar source and Dockerfile came from, into <a rel="noreferrer" target="_blank" href="https://slsa.dev/provenance/v0.2#materials">materials</a> .<br> Copying the reported dependencies of acorn://foo@abc and oppy://baz@def into <a rel="noreferrer" target="_blank" href="https://slsa.dev/provenance/v0.2#materials">materials</a> and adding their attestations to the output <a rel="noreferrer" target="_blank" href="https://github.com/in-toto/attestation/blob/main/spec/bundle.md">in-toto bundle</a> .<br> Recording the CI/CD entrypoint as the <a rel="noreferrer" target="_blank" href="https://slsa.dev/provenance/v0.2#invocation">invocation</a> .<br> Creating a signed <a rel="noreferrer" target="_blank" href="https://github.com/secure-systems-lab/dsse">DSSE</a> with the SLSA provenance and adding it to the output <a rel="noreferrer" target="_blank" href="https://github.com/in-toto/attestation/blob/main/spec/bundle.md">in-toto bundle</a> .<br> Once the container is ready for release the Acme verifier checks the SLSA provenance (and other data in the in-toto bundle) using the policy from their own policy repo and issues a VSA. The VSA and all associated attestations are then published to an internal Rekor instance. Acme can then create an <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Software_bill_of_materials">SBOM</a> for the container leveraging data about the build as stored in Rekor. Acme then publishes the container image, the VSA, and the SBOM on Dockerhub. Downstream users of this Acme container can then check the Acme issued VSA, and if there are any problems Acme can consult their internal Rekor instance to get more details on the build allowing Acme to trace all of their dependencies back to source code and the systems used to create them. Conclusion With SLSA implemented in the ways described in this series, downstream users are protected from many of <a rel="noreferrer" target="_blank" href="https://slsa.dev/spec/v0.1/threats">the threats affecting the software supply chain today</a> . While users still need to trust certain parties, the number of systems requiring trust is much lower and users are in a much better position to investigate any issues that arise. We’d love to see the ideas in this series implemented, refuted, or used as a foundation to build even stronger solutions. We’d also love to hear some other methods on how to solve these issues. <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa#get-involved">Show us</a> how you like to SLSA.<br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/how-to-slsa-part-2-details.html">How to SLSA Part 2 - The Details</a><br> <hr> Posted by Tom  Hennen, software engineer, BCID & GOSST<br> In <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/how-to-slsa-part-1-basics.html">our last post</a> we introduced a fictional example of Squirrel, Oppy, and Acme learning to use SLSA and covered the basics of what their implementations might look like. Today we’ll cover the details: where to store attestations and policies, what policies should check, and how to handle key distribution and trust.<br> Attestation storage<br> Attestations play a large role in SLSA and it’s essential that consumers of artifacts know where to find the attestations for those artifacts.<br> Co-located in repo Attestations could be colocated in the repository that hosts the artifact. This is how Squirrel plans to store attestations for packages. They even want to add support to the Squirrel CLI (e.g. acorn get-attestations foo@1.2.3). Acme really likes this approach because the attestations are always available and it doesn’t introduce any new dependencies.<br> Rekor<br> Meanwhile, Oppy plans to store attestations in <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/rekor">Rekor</a> . They like being able to direct users to an existing public instance while not having to maintain any new infrastructure themselves, and the in-depth defense the transparency log provides against tampering with the attestations. Though the latency of querying attestations from Rekor is likely too high for doing verification at time of use, Oppy isn’t too concerned since they expect users to query Rekor at install time. Hybrid A hybrid model is also available where the publisher stores the attestations in Rekor as well as co-located with the artifact in the repo—along with Rekor’s inclusion proof. This provides confidence the data was added to Rekor while providing the benefits of co-locating attestations in the repository.<br> Policy content<br> ‘Policy’ refers to the rules used to determine if an artifact should be allowed for a use case. Policies often use the package name as a proxy for determining the use case. An example being, if you want to find the policy to apply you could look up the policy using the package name of the artifact you’re evaluating. Policy specifics may vary based on ease of use, availability of data, risk tolerance and more. Full verification needs more from policies than delegated verification does.<br> Default policy Default policies allow admission decisions without the need to create specific policies for each package. A default policy is a way of saying “anything that doesn’t have a more specific policy must comply with this policy”. Squirrel plans to eventually implement a default policy of “any package without a more specific policy will be accepted as long as it meets SLSA 3”, but they recognize that most packages don’t support this yet. Until they achieve critical mass they’ll have a default SLSA 0 policy (all artifacts are accepted). While Oppy is leaving verification to their users, they’ll suggest a default policy of “any package built by ‘https://oppy.example/slsa/builder/v1’”.<br> Specific policy Squirrel also plans to allow users to create policies for specific packages. For example, this policy requires that package ‘foo’ must have been built by GitHub Actions, from github.com/foo/acorn-foo, and be SLSA 4.<br> scope : 'acorn://foo'<br> target_level : SLSA_L4<br> allow_github_actions {<br> workflow : 'https://github.com/gossts/slsa-acorn/.github/workflows/builder.yml@main'<br> source_repo : 'https://github.com/foo/acorn-foo.git'<br> allow_branch : 'main'<br> Squirrel will also allow packages to create SLSA 0 policies if they’re not using SLSA compliant infrastructure.<br> scope : 'acorn://qux'<br> Policy auto generation<br> Squirrel has an enormous number of existing packages. It’s not feasible to get all those package maintainers to create specific policies themselves. Therefore, Squirrel plans to leverage <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Process_mining">process mining</a> to auto generate policies for packages based on the history of the package. E.g. “The last 10 times Squirrel package foo was published it was built by GitHub Actions from github.com/foo/acorn-foo, and met SLSA 4 (this is the policy above). Let’s create a policy that requires that and send it to the maintainers to review.” Policy add-ons Policy evaluation could do more than just evaluate the SLSA requirements. The same policies that check SLSA requirements are well placed to check other properties that are important to organizations like “was static analysis performed”, “are there any known CVEs in this artifact”, “was integration testing successful”, etc… Acme is really interested in some of these policy add-ons. They’d like to avoid the embarrassing situation of publishing a new container image with known CVEs. They’re not sure how to implement it yet but they’ll be on the lookout for tools that can help them do so.<br> Delegated policies When using delegated verification there’s much less that actually needs to be checked and they can be hard-coded directly in tooling. A minimal delegated verification policy might be “allow if trusted-party verified this artifact (identified by digest) as <package name>”. This can be tightened further by adding requirements on the artifact & its dependencies SLSA levels (data which is available in the VSA). For example, “allow if trusted-party verified this artifact as <package name> at SLSA 3 and it doesn’t have any dependencies less than SLSA 2”.<br> # Delegated verification implicitly checks that the package name we're<br> # checking matches the VSA's subject.name field.<br> allow_delegated_verification {<br> trusted_verifier : 'https://delegatedverifier.com/slsa/v1'<br> minimum_level : SLSA_L3<br> minimum_dependency_level : SLSA_L2<br> Policy storage<br> When using specific, non-default, policies … https://www.whatsupup.com/blog/ewing/undiscernibly/20220407-161437/ Thu, 07 Apr 2022 16:14:37 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220407-161437/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/improving-software-supply-chain.html">Improving software supply chain security with tamper-proof builds</a><br></p> <hr> Posted by Asra Ali and Laurent Simon, Google Open Source Security Team (GOSST)<br> Many of the recent high-profile software attacks that have alarmed open-source users globally were consequences of supply chain integrity vulnerabilities: attackers gained control of a build server to <a rel="noreferrer" target="_blank" href="https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/">use malicious source files</a> , <a rel="noreferrer" target="_blank" href="https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/">inject malicious artifacts</a> into a compromised build platform, and bypass trusted builders to <a rel="noreferrer" target="_blank" href="https://about.codecov.io/apr-2021-post-mortem/">upload malicious artifacts</a> . Each of these attacks could have been prevented if there were a way to detect that the delivered artifacts diverged from the expected origin of the software. But until now, generating verifiable information that described where, when, and how software artifacts were produced (information known as provenance) was difficult. This information allows users to trace artifacts verifiably back to the source and develop risk-based policies around what they consume. Currently, provenance generation is not widely supported, and solutions that do exist may require migrating build processes to services like <a rel="noreferrer" target="_blank" href="https://github.com/tektoncd/chains">Tekton Chains</a> . This blog post describes a new method of generating non-forgeable provenance using <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-workflows">GitHub Actions workflows</a> for isolation and <a rel="noreferrer" target="_blank" href="https://www.sigstore.dev/">Sigstore’s</a> signing tools for authenticity. Using this approach, projects building on GitHub runners can achieve <a rel="noreferrer" target="_blank" href="https://slsa.dev/spec/v0.1/requirements">SLSA 3</a> (the third of four progressive SLSA “levels”), which affirms to consumers that your artifacts are authentic and trustworthy.<br> Provenance<br> <a rel="noreferrer" target="_blank" href="https://slsa.dev/">SLSA</a> ("Supply-chain Levels for Software Artifacts”) is a framework to help improve the integrity of your project throughout its development cycle, allowing consumers to trace the final piece of software you release all the way back to the source. Achieving a high SLSA level helps to improve the trust that your artifacts are what you say they are. This blog post focuses on build provenance, which gives users important information about the build: who performed the release process? Was the build artifact protected against malicious tampering? Source provenance describes how the source code was protected, which we’ll cover in future blog posts, so stay tuned.<br> Go prototype to generate non-forgeable build provenance<br> To create tamperless evidence of the build and allow consumer verification, you need to:<br> Isolate the provenance generation from the build process;<br> Isolate against maintainers interfering in the workflow;<br> Provide a mechanism to identify the builder during provenance verification.<br> The full isolation described in the first two points allows consumers to trust that the provenance was faithfully recorded; entities that provide this guarantee are called trusted builders. Our <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa-github-generator-go">Go prototype</a> solves all three challenges. It also includes running the build inside the trusted builder, which provides a strong guarantee that the build achieves SLSA 3’s <a rel="noreferrer" target="_blank" href="https://slsa.dev/spec/v0.1/requirements#ephemeral-environment">ephemeral</a> and <a rel="noreferrer" target="_blank" href="https://slsa.dev/spec/v0.1/requirements#isolated">isolated</a> requirement.<br> How does it work?<br> The following steps create the trusted builder that is necessary to generate provenance in isolation from the build and maintainer’s interference.<br> Step One: Create a reusable workflow on GitHub runners Leveraging GitHub’s <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-workflows/reusing-workflows">reusable workflows</a> provides the isolation mechanism from both maintainers’ caller workflows and from the build process. Within the workflow, Github Actions creates <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#the-components-of-github-actions">fresh instances of virtual machines (VMs), called runners, for each job</a> . These separate VMs give the necessary isolation for a trusted builder, so that different VMs compile the project and generate and sign the SLSA provenance (see diagram below). Running the workflow on <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners">GitHub-hosted runners</a> gives the guarantee that the code run is in fact the intended workflow, which <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners">self-hosted runners</a> do not. This prototype relies on GitHub to run the exact code defined in the workflow. The reusable workflow also protects against possible interference from maintainers, who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which stops maintainers from altering information via <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#env">environment variables</a> , <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps">steps</a> , <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservices">services</a> and <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults">defaults</a> . To protect against the possibility of one job (e.g. the build step) tampering with the other artifacts used by another job (the provenance step), this approach uses a trusted channel to protect the integrity of the data. We use <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs">job outputs</a> to send hashes (due to size limitations) and then use the hashes to verify the binary received via the untrusted artifact registry.<br> Step 2: Use OpenID Connect (OIDC) to prove the identity of the workflow to an external service (Sigstore) OpenID Connect (OIDC) is a standard used across the web for identity providers (e.g., Google) to attest to the identity of a user for a third party. GitHub now <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect">supports</a> OIDC in their workflows. Each time a workflow is run, a runner can mint a unique <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token">JWT token</a> from GitHub’s OIDC provider. The token contains verifiable information of the workflow identity, including the caller repository, commit hash, trigger, and the current (reuseable) workflow path and reference. Using OIDC, the workflow proves its identity to <a rel="noreferrer" target="_blank" href="https://www.sigstore.dev/">Sigstore's</a> Fulcio root Certificate Authority, which acts as an external verification service. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner and tying it to the workload identity. A record of signing the provenance is kept in Sigstore’s transparency log <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/rekor">Rekor</a> . Users can use the signing certificate as a trust anchor to verify that the provenance was authenticated and non-forgeable; it must have been created inside the trusted builder.<br> Verification<br> The consumer can verify the artifact and its signed provenance with these steps:<br> Look up the corresponding Rekor log entry and verify the signature;<br> Verify the trusted builder identity by extracting it from the signing certificate;<br> Check that the provenance information matches the expected source and build.<br> See an <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa-github-generator-go">example in action</a> in the official repository. Performing these steps guarantees to the consumer that the binary was produced in the trusted builder at a given commit hash attested to in the provenance. They can trust that the information in the provenance was non-forgeable, allowing them to trust the build “recipe” and trace their artifact verifiably back to the source.<br> Extra Bonus: Keyless signing<br> One extra benefit of this method is that maintainers don’t need to manage or distribute cryptographic keys for signing, avoiding the <a rel="noreferrer" target="_blank" href="https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/">notoriously difficult problem</a> of key management. The OIDC protocol requires no hardcoded, long-term secrets be stored in GitHub's secrets, which sidesteps the potential problem of key mismanagement invalidating the SLSA provenance. Consumers simply use OIDC to verify that the binary artifact was built from a trusted builder that produced the expected provenance.<br> Next Steps<br> Utilizing the SLSA framework is a proven way for ensuring software supply-chain integrity at scale. This prototype shows that achieving high SLSA levels is easier than ever thanks to the newest features of popular CI/CD systems and open-source tooling. Increased adoption of tamper-safe (SLSA 3+) build services will contribute to a stronger open-source ecosystem and help close one easily exploited gap in the current supply chain. We encourage testing and adoption and welcome any improvements to the project. Please share feedback, comments and suggestions at <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa-github-generator-go">slsa-github-generator-go</a> and <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa-verifier">slsa-verifier</a> project repositories. We will officially release v1 in a few weeks! In follow-up posts, we will demonstrate adding non-forgeable source provenance attesting to secure repository settings, and showcase the same techniques for other build toolchains and package managers, etc. Stay tuned!<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220405-161319/ Tue, 05 Apr 2022 16:13:19 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220405-161319/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/04/find-and-eek-increased-rewards-for.html">Find and $eek! Increased rewards for Google Nest & Fitbit devices</a><br></p> <hr> Posted by Medha Jain, Program Manager, Devices & Services Security<br> At Google, we constantly invest in security research to raise the bar for our devices, keeping our users safe and building their trust in our products. In 2021, we published <a rel="noreferrer" target="_blank" href="https://safety.google/nest/">Google Nest security commitments</a> , in which we committed to engage with the research community to examine our products and services and report vulnerabilities. We are now looking to deepen this relationship and accelerate the path toward building more secure devices. Starting today, we will introduce a new vulnerability rewards structure for submissions impacting <a rel="noreferrer" target="_blank" href="https://store.google.com/category/connected_home?e=SharedFeatureEnablePolarisNavTest%3A%3ALaunch&hl=en-US">smart home</a> (Google Nest) and <a rel="noreferrer" target="_blank" href="https://store.google.com/category/fitbit?e=SharedFeatureEnablePolarisNavTest%3A%3ALaunch&hl=en-US">wearables</a> (Fitbit) devices through our <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about">Bug Hunters</a> platform. Bonus!<br> We are paying higher rewards retroactively for eligible Google Nest and Fitbit devices reports submitted in 2021. And, starting today, for the next six months, will double the reward amount for all new eligible reports applicable to Google Nest & Fitbit devices in scope. We will continue to take reports on our web applications, services, and mobile apps at their existing reward levels. Please keep those coming! An enhanced rewards program<br> Building on our previous programs to improve devices' embedded security posture, we’re bringing all our first-party devices under a single program, starting with Google Nest, Fitbit, and Pixel. This program extends the Android Security Reward Program, making it easier for researchers to submit a vulnerability in first-party devices and improving consistency across our severity assignments. Refer to the <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/6171833274204160/android-security-rewards-program-rules">Android and Google Devices Security Reward Program</a> for more details. What interests us?<br> We encourage researchers to report firmware, system software, and hardware vulnerabilities. Our wide diversity of platforms provides researchers with a smorgasbord of environments to explore. What's next?<br> We will be at the <a rel="noreferrer" target="_blank" href="http://Hardwear.io">Hardwear.io</a> conference this year! The VRP team is looking forward to meeting our security peers in person. We’ll be talking about the architecture of a couple of our devices, hoping to give security researchers a head start in finding vulnerabilities. We’ll have plenty of swag, too! We will continue to enhance the researchers' experience and participation. We intend to add training documentations and target areas that interest us as we grow the program. A huge thanks to Sarah Jacobus, Adam Bacchus, Ankur Chakraborty, Eduardo' Vela" <Nava>, Jay Cox, and Nic Watson.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220310-201302/ Thu, 10 Mar 2022 20:13:02 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220310-201302/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits-plus.html">What's up with in-the-wild exploits? Plus, what we're doing about it.</a><br></p> <hr> Posted by Adrian Taylor, Chrome Security Team<br> If you are a regular reader of our <a rel="noreferrer" target="_blank" href="https://chromereleases.googleblog.com/search/label/Stable%20updates">Chrome release blog</a> , you may have noticed that phrases like 'exploit for CVE-1234-567 exists in the wild' have been appearing more often recently. In this post we'll explore why there seems to be such an increase in exploits, and clarify some misconceptions in the process. We'll then share how Chrome is continuing to make it harder for attackers to achieve their goals.<br> How things work today<br> While the increase may initially seem concerning, it’s important to understand the reason behind this trend. If it's because there are many more exploits in the wild, it could point to a worrying trend. On the other hand, if we’re simply gaining more visibility into exploitation by attackers, it's actually a good thing! It’s good because it means we can respond by providing bug fixes to our users faster, and we can learn more about how real attackers operate.<br> So, which is it? It’s likely a little of both.<br> Our colleagues at Project Zero <a rel="noreferrer" target="_blank" href="https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1123292625">publicly track all known in-the-wild “zero day” bugs</a> . Here’s what they’ve reported for browsers:<br> First, we don’t believe there was no exploitation of Chromium based browsers between 2015 and 2018. We recognize that we don’t have full view into active exploitation, and just because we didn’t detect any zero-days during those years, doesn’t mean exploitation didn’t happen. Available exploitation data suffers from sampling bias.<br> Teams like Google’s <a rel="noreferrer" target="_blank" href="https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks/">Threat Analysis Group</a> are also becoming increasingly sophisticated in their efforts to protect users by discovering zero-days and in-the-wild attacks. A good example is <a rel="noreferrer" target="_blank" href="https://www.youtube.com/watch?v=g09EvzVsDbk">a bug in our Portals feature</a> that we fixed last fall. This bug was discovered by a team member in Switzerland and reported to Chrome through our bug tracker. While Chrome normally keeps each web page locked away in a box called the “renderer sandbox,” this bug allowed the code to break out, potentially allowing attackers to steal information. Working across multiple time zones and teams, it took the team three days to come up with a fix and roll it out, as detailed in our video on the process:<br> Why so many exploits?<br> There are a number of factors at play, from changes in vendor and attacker behavior, to changes in the software itself. Here are four in particular that we've been discussing and exploring as a team.<br> First, we believe we’re seeing more bugs thanks to vendor transparency. Historically, many browser makers didn’t announce that a bug was being exploited in the wild, even if they knew it was happening. Today, most major browser makers have increased transparency via publishing details in release communications, and that may account for more publicly tracked “in the wild” exploitation. These efforts have been spearheaded by both browser security teams and dedicated research groups, such as <a rel="noreferrer" target="_blank" href="https://googleprojectzero.blogspot.com/">Project Zero.</a><br> Second, we believe we’re seeing more exploits due to evolved attacker focus. There are two reasons to suspect attackers might be choosing to attack Chrome more than they did in the past.<br> Flash deprecation : In 2015 and 2016, Flash was a primary exploitation target. Chrome gradually made Flash a less attractive target for attackers <a rel="noreferrer" target="_blank" href="https://www.chromium.org/flash-roadmap/">(for instance requiring user clicks to activate Flash content)</a> before finally removing it in Chrome 88 in January last year. As Flash is no longer available, attackers have had to switch to a harder target: the browser itself.<br> Chromium popularity : Attackers go for the most popular target. In early 2020, Edge switched to using the Chromium rendering engine. If attackers can find a bug in Chromium, they can now attack a greater percentage of users.<br> Third, some attacks that could previously be accomplished with a single bug now require multiple bugs. Before 2015, only a single in-the-wild bug was required to steal a user’s secrets from other websites, because multiple web pages lived together in a single <a rel="noreferrer" target="_blank" href="https://www.chromium.org/developers/design-documents/multi-process-architecture">renderer process</a> . If an attacker could compromise the renderer process belonging to a malicious website that a user visited, they might have been able to access the credentials for some other more sensitive website.<br> With Chrome’s multiyear <a rel="noreferrer" target="_blank" href="https://www.chromium.org/Home/chromium-security/site-isolation">Site Isolation</a> project largely complete, a single bug is almost never sufficient to do anything really bad. Attackers often need to chain at least two bugs: first, to compromise the renderer process, and second, to jump into the privileged Chrome browser process or directly into the device operating system. Sometimes multiple bugs are needed to achieve one or both of these steps.<br> So, to achieve the same result, an attacker generally now has to use more bugs than they previously did. For exactly the same level of attacker success, we’d see more in-the-wild bugs reported over time, as we add more layers of defense that the attacker needs to bypass.<br> Fourth, there’s simply the fact that software has bugs . Some fraction of those bugs are exploitable. Browsers increasingly mirror the complexity of operating systems — providing access to your peripherals, filesystem, 3D rendering, GPUs — and more complexity means more bugs.<br> Ultimately, we believe data is an important part of the story, but the absolute number of exploited bugs isn't a sufficient measure of security risk. Since some security bugs are inevitable, how a software vendor architects their software (so that the impact of any single bug is limited) and responds to critical security bugs is often much more important than the specifics of any single bug.<br> How Chrome is raising the bar<br> The Chrome team works hard to both detect and fix bugs before releases and get bug fixes out to users as quickly as possible. We’re proud of <a rel="noreferrer" target="_blank" href="https://googleprojectzero.blogspot.com/2022/02/a-walk-through-project-zero-metrics.html">our record at fixing serious bugs quickly</a> , and we are continually working to do better.<br> For example, one area of concern for us is the risk of n-day attacks: that is, exploitation of bugs we’ve already fixed, where the fixes are visible in our open-source code repositories. We have greatly reduced our “patch gap” from 35 days in Chrome 76 to an average of 18 days in subsequent milestones, and we expect this to reduce slightly further with <a rel="noreferrer" target="_blank" href="https://blog.chromium.org/2021/03/speeding-up-release-cycle.html">Chrome’s faster release cycle</a> .<br> Irrespective of how quickly bugs are fixed, any in-the-wild exploitation is bad. Chrome is working hard to make it expensive and difficult for attackers to achieve their goals.<br> Some examples of the projects ongoing:<br> We continue to strengthen Site Isolation, <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/protecting-more-with-site-isolation.html">especially on Android</a> .<br> <a rel="noreferrer" target="_blank" href="https://docs.google.com/document/d/1FM4fQmIhEqPG8uGp5o9A-mnPB5BOeScZYpkHjo0KKA8/edit#heading=h.fg3qxf1x0p2q">The V8 heap sandbox</a> will prevent attackers using JavaScript just-in-time (JIT) compilation bugs to compromise the renderer process. This will require attackers to add a third bug to these exploit chains, which means increased security, but could increase the amount of in-the-wild exploits reported.<br> The <a rel="noreferrer" target="_blank" href="https://www.youtube.com/watch?v=gevcleRHRZ4">MiraclePtr and *Scan</a> projects aim to prevent exploitability of many of our largest class of browser process bugs, called “use-after-free”. We will be applying similar systematic solutions to other classes of bugs over time.<br> Since “memory safety” bugs account for 70% of the exploitable security bugs, we aim to write new parts of Chrome in <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html">memory-safe languages</a> .<br> We continue to work on post-exploitation mitigations such as <a rel="noreferrer" target="_blank" href="https://www.intel.com/content/www/us/en/developer/articles/technical/technical-look-control-flow-enforcement-technology.html">CET</a> and <a rel="noreferrer" target="_blank" href="https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard">CFG</a> .<br> We are well past the stage of having “easy wins” when it comes to raising the bar for security. All of these are long term projects with significant engineering challenges. But as we've shown with Site Isolation, Chrome isn't afraid of making long term investments in major security engineering projects. One of the major challenges is performance: all of these technologies (except memory safe languages) could risk slowing the browser. Expect a series of blog posts over the coming months as we explore performance vs. security trade-offs. These decisions are really hard : we do not want to make Chrome slower for billions of people, especially as this disproportionately hits users with slower devices – we strive to make Chrome secure for all our users, not just those with the high end systems.<br> How you can help<br> Above all: if Chrome is reminding you to update, please do!<br> If you’re an enterprise IT professional, keep your users up-to-date by keeping auto-update on, and familiarize yourself with <a rel="noreferrer" target="_blank" href="https://chromeenterprise.google/browser/security/">the added enterprise policies and controls</a> that you can apply to Chrome within your organization. We strongly advise not focusing on zero-days when making decisions about updates, but instead to assume any Chrome security bug is under exploitation as an n-day.<br> If you're a security researcher, you can report bugs you find to the <a rel="noreferrer" target="_blank" href="https://g.co/chrome/vrp">Chrome Vulnerability Rewards Program</a> — and thanks for helping us make Chrome safer for everyone!<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220223-201346/ Wed, 23 Feb 2022 20:13:45 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220223-201346/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/02/mitigating-kernel-risks-on-32-bit-arm.html">Mitigating kernel risks on 32-bit ARM</a><br></p> <hr> Posted by Ard Biesheuvel, Google Open Source Security Team Linux kernel support for the 32-bit ARM architecture was contributed in the late 90s, when there was little corporate involvement in Linux development, and most contributors were students or hobbyists, tinkering with development boards, often without much in the way of documentation.<br> Now 20+ years later, 32-bit ARM's maintainer has downgraded its support level to <a rel="noreferrer" target="_blank" href="https://git.kernel.org/linus/18bd49043caa8b272649d4868c29133eb0a3d143">'odd fixes</a> ,' while remaining active as a kernel contributor. This is a common pattern for aging and obsolete architectures: corporate funding for Linux kernel development has tremendously increased the pace of development, but only for architectures with a high return on investment. As a result, the 32-bit ARM port of Linux is essentially in maintenance-only mode, and lacks core Linux advancements such as THREAD_INFO_IN_TASK or VMAP_STACK, which protect against stack overflow attacks. The lack of developer attention does not imply that the 32-bit ARM port has ceased to make economic sense, though. Instead, it has evolved from being one of the spearheads of Linux innovation to a stable and mature platform, and while funding its upstream development may not make sense in the long term, deploying 32-bit ARM into the field today most certainly still makes economic sense when margins are razor thin and <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Bill_of_materials">BOM</a> costs need to be kept to an absolute minimum. This is why 32-bit ARM is still widely used in embedded systems like set-top boxes and wireless routers.<br> Running 32-bit Linux on 64-bit ARM systems Ironically, at these low price points, the DRAM is actually the dominant component in terms of BOM cost, and many of these 32-bit ARM systems incorporate a cheap ARMv8 <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/System_on_a_chip">SoC</a> that happens to be capable of running in 64-bit mode as well. The reason for running 32-bit applications nonetheless is that these generally use less of the expensive DRAM, and can be deployed directly without the need to recompile the binaries. As 32-bit applications don't need a 64-bit kernel (which itself uses more memory due to its internal use of 64-bit pointers), the product ships with a 32-bit kernel instead. If you're choosing to use a 32-bit kernel for its smaller memory footprint, it's not without risks. You'll likely experience performance issues, unpatched vulnerabilities, and unexpected misbehaviors such as:<br> 32-bit kernels generally cannot manage more than 1 GiB of physical memory without resorting to HIGHMEM bouncing, and cannot provide a full virtual address space of 4 GiB to user space, as 64-bit kernels can.<br> Side channels or other flaws caused by silicon errata may exist that haven't been mitigated in 32-bit kernels. For example, the hardening against Spectre and Meltdown vulnerabilities were only done for ARMv7 32-bit only CPUs, and many ARMv8 cores running in 32-bit mode may still be vulnerable (only Cortex-A73 and A75 are handled specifically). And in general, silicon flaws in 64-bit parts that affect the 32-bit kernel are less likely to be found or documented, simply because the silicon validation teams don’t prioritize them.<br> The 32-bit ARM kernel does not implement the elaborate <a rel="noreferrer" target="_blank" href="https://youtu.be/CUAXCeRjw3c?t=2687">alternatives patching framework</a> that is used by other architectures to implement handling of silicon errata, which are particular to certain revisions of certain CPUs. Instead, on 32-bit multiplatform kernels, we simply enable all errata workarounds that may be needed by any of the cores that may ever run the image in question, potentially affecting performance unnecessarily on cores that have no need for them.<br> Silicon vendors are phasing out 32-bit support in the longer term. Given an ecosystem containing a handful of operating systems and thousands of applications, support for 32-bit operating systems (which is more complex technically) is highly likely to be dropped first. For products with longer life cycles, long-term procurement contracts for components available today are usually much more costly than adjusting the BOM over time and using newer, cheaper parts.<br> The 32-bit kernel does not implement <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f80fb3a3d50843a401dac4b566b3b131da8077a2">kernel address space randomization</a> , and even if it did, its comparatively tiny address space simply leaves very little space for randomization. Other hardening features, such as <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c55191e96caa9">rodata=full</a> or <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=87143f404f338">hierarchical eXecute Never attributes</a> , are missing as well on 32-bit, and are not likely to be implemented, either due to lack of support in the architecture, or because of the complexity of the 32-bit memory management code, which still supports all of the different architecture revisions dating back to the initial Linux port running on the <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Risc_PC">Risc PC</a> .<br> Keeping the 32-bit ARM kernel secure There are cases, though, where using the 32-bit kernel is the only option, e.g., if the CPUs are in fact 32-bit only (which is the case even for some ARMv8 cores such as Cortex-A32), or when relying on an existing 32-bit only codebase running in the kernel (drivers for legacy peripherals). Note that in such cases, it still makes sense to use the most recent kernel version compatible with the hardware, since we are in fact making an effort to enable some of the existing hardening features on 32-bit ARM as well.<br> THREAD_INFO_IN_TASK for v7 SMP cores<br> The v5.16 release of the Linux kernel <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18ed1c01a7dd3d7c780b06a49124da237a4c1790">implements</a> support for THREAD_INFO_IN_TASK when running on ARMv7 SMP systems. This protects the kernel's per-task bookkeeping (called thread_info), which lives on the far (and normally unused) end of the stack, against stack overflows which may occur in rare -yet sometimes exploitable- cases where the control flow of the program simply ends up accumulating more state than the stack can hold. (Note that a stack overflow is not the same as a stack buffer overflow, where the overflow happens in the opposite direction.)<br> By moving thread_info off the stack and into the kernel heap, and by using a special SMP CPU register to keep track of its location, we can mitigate the risk of stack overflows resulting in thread_info corruption. However, it does not prevent stack overflows themselves: these may still occur, and result in corruption of other data structures that happen to be adjacent to the task stack in memory.<br> THREAD_INFO_IN_TASK for other cores<br> For CPUs that lack this special SMP CPU register, we also proposed an implementation of THREAD_INFO_IN_TASK that is expected to land in v5.18. Instead of a special register, it uses a global variable to keep track of the location of thread_info.<br> VMAP_STACK support<br> Preventing stack overflows from corrupting unrelated memory contents is the goal of VMAP_STACK, which we are <a rel="noreferrer" target="_blank" href="https://lore.kernel.org/linux-arm-kernel/20211122092816.2865873-1-ardb@kernel.org/">enabling for 32-bit ARM</a> as well. When VMAP_STACK is enabled, kernel mode stacks are allocated from the kernel heap as before, but mapped into a different part of the kernel's address space, and surrounded by guard regions, which are guaranteed to be kept unpopulated. Given that accesses to such unpopulated regions will trigger an exception, the kernel's memory management layer can step in and terminate the program as soon as a stack overflow occurs, and prevent it from causing memory corruption.<br> Support for IRQ stacks Coming up with a bounded worst case on which to base the size of the kernel stack is rather hard, especially given the fact that it is shared between the program itself and any exception handling routines that may be called on its behalf, including interrupt handlers. To mitigate the risk of a pathological worst case occurring, where an interrupt fires that needs a lot of stack space right at a time when most of the stack is already being used by the program, we are also <a rel="noreferrer" target="_blank" href="https://lore.kernel.org/linux-arm-kernel/20211115084732.3704393-1-ardb@kernel.org/">enabling IRQ_STACKS for 32-bit ARM</a> , which will run handlers of both hard and soft interrupts from a dedicated stack, one for each CPU. By decoupling the task and interrupt contexts like this, the likelihood that a well-behaved program needs to be terminated due to stack overflow should be all but eliminated.<br> Conclusion With <a rel="noreferrer" target="_blank" href="https://lore.kernel.org/linux-arm-kernel/20211208092611.1012773-1-ardb@kernel.org/">these changes</a> in place, kernel stack overflow protection will be available for all ARM systems supported by Linux, including ancient ones like the Risc PC or <a rel="noreferrer" target="_blank" href="https://lore.kernel.org/linux-arm-kernel/874k7pn923.wl-maz@kernel.org/">Netwinder</a> , provided that it runs a Linux distribution that is <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html">keeping up with the times.</a><br> However, relying on legacy hardware and software comes with a risk, and even though we try to help keep users of the 32-bit kernel as safe as we reasonably can, it is not the right choice for new designs that incorporate 64-bit capable hardware.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220214-201347/ Mon, 14 Feb 2022 20:13:46 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220214-201347/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/02/roses-are-red-violets-are-blue-giving.html">🌹 Roses are red, Violets are blue 💙 Giving leets 🧑‍💻 more sweets 🍭 All of 2022!</a><br></p> <hr> Posted by Eduardo Vela, Vulnerability Matchmaker<br> Until December 31 2022 we will pay 20,000 to 91,337 USD for exploits of vulnerabilities in the Linux Kernel, Kubernetes, GKE or kCTF that are exploitable on our test lab. We launched an <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/11/trick-treat-paying-leets-and-sweets-for.html">expansion</a> of kCTF VRP on November 1, 2021 in which we paid 31,337 to 50,337 USD to those that are able to compromise our kCTF cluster and obtain a flag. We increased our rewards because we recognized that in order to attract the attention of the community we needed to match our rewards to their expectations. We consider the expansion to have been a success, and because of that we would like to extend it even further to at least until the end of the year (2022). During the last three months, we received 9 submissions and paid over 175,000 USD so far. The submissions included five 0days and two 1days. Three of these are already fixed and are public: <a rel="noreferrer" target="_blank" href="https://access.redhat.com/security/cve/cve-2021-4154">CVE-2021-4154</a> , <a rel="noreferrer" target="_blank" href="https://ubuntu.com/security/CVE-2021-22600">CVE-2021-22600</a> ( <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec6af094ea28f0f2dda1a6a33b14cd57e36a9755">patch</a> ) and <a rel="noreferrer" target="_blank" href="https://ubuntu.com/security/CVE-2022-0185">CVE-2022-0185</a> ( <a rel="noreferrer" target="_blank" href="https://www.willsroot.io/2022/01/cve-2022-0185.html">writeup</a> ). These three bugs were first found by <a rel="noreferrer" target="_blank" href="https://syzkaller.appspot.com/upstream">Syzkaller</a> , and two of them had already been fixed on the mainline and stable versions of the Linux Kernel at the time they were reported to us. Based on our experience these last 3 months, we made a few improvements to the submission process:<br> Reporting a 0day will not require including a flag at first. We heard some concerns from participants that exploiting a 0day in the shared cluster could leak it to other participants. As such, we will only ask for the exploit checksum (but you still have to exploit the bug and submit the flag within a week after the patch is merged on <a rel="noreferrer" target="_blank" href="https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux">mainline</a> ). Please make sure that your exploit <a rel="noreferrer" target="_blank" href="https://cloud.google.com/container-optimized-os/docs/concepts/security#security-hardened_kernel">works on COS</a> with minimal modifications (test it on your own <a rel="noreferrer" target="_blank" href="https://github.com/google/google-ctf/tree/master/vrp">kCTF cluster</a> ), as some common exploit primitives (like eBPF and userfaultfd) might not be available.<br> Reporting a 1day will require including a link to the patch. We will automatically publish the patches of all submissions if the flag is valid. We also encourage you all to include a link to a Syzkaller dashboard report if applicable in order to help reduce duplicate submissions and so you can see which bugs were exploited already.<br> You will be able to submit the exploit in the same form you submit the flag. If you had submitted an exploit checksum for a 0day, please make sure that you include the original exploit as well as the final exploit and make sure to submit it within a week after the patch is merged on <a rel="noreferrer" target="_blank" href="https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux">mainline</a> . The original exploit shouldn't require major modifications to work. Note that we need to be able to understand your exploit, so please add comments to explain what it is doing.<br> We are now running two clusters, one on the <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/release-notes-regular">REGULAR</a> release channel and another one on the <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/release-notes-rapid">RAPID</a> release channel. This should provide more flexibility whenever a vulnerability is only exploitable on modern versions of the Linux Kernel or Kubernetes.<br> We are also changing the reward structure slightly. Going forward the rewards will be:<br> 31,337 USD to the first valid exploit submission for a given vulnerability. This will only be paid once per vulnerability and only once per cluster version/build (available at /etc/node-os-release).<br> 0 USD for exploits for duplicate exploits for the same vulnerability. The bonuses below might still apply.<br> Bonuses<br> 20,000 USD for exploits for 0day vulnerabilities. This will only be paid once per vulnerability to the first valid exploit submission.<br> To submit 0days, please test your exploit (we recommend to test it on your own kCTF cluster to avoid leaking it to other participants), make a checksum and send the checksum to us. Within a week after the vulnerability is fixed on the <a rel="noreferrer" target="_blank" href="https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux">mainline</a> , submit the form as a 1day and include the exploit of which you sent a checksum to us.<br> 20,000 USD for exploits for vulnerabilities that do not require unprivileged user namespaces (CLONE_NEWUSER). This will only be paid once per vulnerability to the first valid exploit submission.<br> Our test lab allows unprivileged user namespaces, so we will manually check the exploits to check if they work without unprivileged user namespaces when deciding whether to issue the bonus. We decided to issue additional rewards for exploits that do not require unprivileged user namespaces because containers <a rel="noreferrer" target="_blank" href="https://github.com/moby/moby/blob/3c06ebd876687555fdf030a3307a66908c4fa57c/profiles/seccomp/default_linux.go#L576">default seccomp policy</a> does not allow the use of unprivileged user namespaces on containers that are run without CAP_SYS_ADMIN. This feature is now <a rel="noreferrer" target="_blank" href="https://kubernetes.io/docs/tutorials/security/seccomp/">available</a> on Kubernetes and all nodes running on <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#container_isolation">GKE Autopilot</a> have it enabled by default.<br> 20,000 USD for exploits using novel exploit techniques. This is a bonus in addition to the base rewards (applies for duplicate exploits). To qualify for this additional reward please send us a write-up explaining it.<br> An example of something considered as a novel technique could be the exploitation of previously unknown objects to transform a limited primitive into a more powerful one, such as an arbitrary/out-of-bounds read/write or arbitrary free. For example, in all our submissions, researchers leveraged message queues to achieve kernel information leaks. We are looking for similarly powerful techniques that allow heap exploits to be “plugged in” and immediately allow kernel access. Another example is bypassing a common security mitigation or a technique for exploiting a class of vulnerabilities more reliably.<br> These changes increase some 1day exploits to 71,337 USD (up from 31,337 USD), and makes it so that the maximum reward for a single exploit is 91,337 USD (up from 50,337 USD). We also are going to pay even for duplicates at least 20,000 USD if they demonstrate novel exploit techniques (up from 0 USD). However, we will also limit the number of rewards for 1days to only one per version/build. There are 12-18 <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/release-notes">GKE releases</a> per year on each channel, and we have two clusters on different channels, so we will pay the 31,337 USD base rewards up to 36 times (no limit for the bonuses). While we don't expect every upgrade to have a valid 1day submission, we would love to learn otherwise. You can find the flag submission status for our clusters (and their versions) <a rel="noreferrer" target="_blank" href="https://google.github.io/kctf/vrp#notes">here</a> . We look forward to hearing from you, and continue to strengthen our shared ecosystem. If you are interested to participate but don't know where to start, Arizona State University has a free public Kernel Exploitation workshop at <a rel="noreferrer" target="_blank" href="https://dojo.pwn.college/challenges/kernel">https://dojo.pwn.college/challenges/kernel</a> as part of an overall memory corruption course and you can find a community-maintained list of past Linux Kernel vulnerabilities, exploits and writeups curated by Andrey Konovalov at <a rel="noreferrer" target="_blank" href="https://github.com/xairy/linux-kernel-exploitation">https://github.com/xairy/linux-kernel-exploitation</a> . This is part of our Vulnerability Reward Program, which we've been running for over 10 years, and <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/6625378258649088">the rules</a> include some more information. Same as with our other rewards, we will double them if they are donated to charity, and submitters will be included on our site at <a rel="noreferrer" target="_blank" href="http://bughunters.google.com/">bughunters.google.com</a> . If you are ready to submit something, please read the instructions on our site <a rel="noreferrer" target="_blank" href="https://google.github.io/kctf/vrp">here</a> and if you have any other questions please contact us <a rel="noreferrer" target="_blank" href="https://discord.gg/V8UqnZ6JBG">on Discord</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220210-201524/ Thu, 10 Feb 2022 20:15:24 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220210-201524/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/02/vulnerability-reward-program-2021-year.html">Vulnerability Reward Program: 2021 Year in Review</a><br></p> <hr> Posted by Sarah Jacobus, Vulnerability Rewards Team<br> Last year was another record setter for our Vulnerability Reward Programs (VRPs). Throughout 2021, we partnered with the security researcher community to identify and fix thousands of  vulnerabilities – helping keep our users and the internet safe.<br> Thanks to these incredible researchers, Vulnerability Reward Programs across Google continued to grow, and we are excited to report that in 2021 we awarded a record breaking $8,700,000 in vulnerability rewards – with researchers donating over $300,000 of their rewards to a charity of their choice.<br> We also <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/a-new-chapter-for-googles-vulnerability.html">launched</a> <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/">bughunters.google.com</a> in 2021, a public researcher portal dedicated to keeping Google products and the internet safe and secure. This new platform brings all of our VRPs (Google, Android, Abuse, Chrome, and Google Play) closer together and provides a single intake form, making security bug submission easier than ever. We’re excited about everything the new Bug Hunters portal has to offer, including:<br> More opportunities for interaction and a bit of healthy competition through gamification, per-country leaderboards, awards/badges for certain bugs, and more!<br> A more functional and aesthetically pleasing <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/leaderboard">leaderboard</a> . We know a lot of you are using your achievements in our VRPs to find jobs (we’re hiring!) and we hope this acts as a useful resource.<br> A stronger emphasis on learning: bug hunters can improve their skills through the content available in our new <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/learn">Bug Hunter University</a><br> Streamlined publication process: we know the value that knowledge sharing brings to our community. That’s why we want to make it easier for you to <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/report/reports">publish your bug reports</a> .<br> We now offer <a rel="noreferrer" target="_blank" href="https://twitter.com/GoogleVRP/status/1420129759833493507">swag</a> ! The first 20 folks who share this blog post on Twitter and tag <a rel="noreferrer" target="_blank" href="https://twitter.com/GoogleVRP">@GoogleVRP</a> will receive a gift voucher for swag in their DMs.<br> As in <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/01/vulnerability-reward-program-2019-year.html">past years</a> , we are sharing our 2021 Year in Review statistics across all of our programs. We would like to give a special thank you to all of our dedicated researchers - we look forward to more collaboration in the future!<br> Android<br> The Android VRP doubled its 2020 total payouts in 2021 with nearly $3 million dollars in rewards, and awarded the highest payout in Android VRP history: an exploit chain discovered in Android receiving a reward of $157,000!<br> Our industry leading prize of $1,500,000 for a compromise of our Titan-M Security chip used in our Pixel device remains unclaimed - for more information on this reward and Android exploit chain rewards, please visit our <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/6171833274204160">public rules page</a> .<br> The program also launched the Android Chipset Security Reward Program (ACSRP), a vulnerability reward program offered by Google in collaboration with manufacturers of certain popular Android chipsets. This private, invite-only program, provides reward and recognition for contributions of security researchers who invest their time and effort into helping make Android devices more secure. In 2021 the ACSRP paid out $296,000 for over 220 valid and unique security reports.<br> We would like to give a special shoutout to some of our top researchers whose continued hard work keeps Android safe and secure:<br> Aman Pandey of <a rel="noreferrer" target="_blank" href="https://bugsmirror.com">Bugsmirror Team</a> has skyrocketed to our top researcher last year, submitting 232 vulnerabilities in 2021! Since submitting their first report in 2019, Aman has reported over 280 valid vulnerabilities to the Android VRP and has been a crucial part of making our program so successful.<br> Yu-Cheng Lin (林禹成) ( <a rel="noreferrer" target="_blank" href="https://twitter.com/AndroBugs">@AndroBugs</a> ) has been another phenomenal researcher for the Android VRP, submitting a whopping 128 valid reports to the program in 2021.<br> Researcher gzobqq@gmail.com discovered a critical exploit chain in Android (CVE-2021-39698) , receiving the highest payout in Android VRP history of $157,000.<br> Chrome<br> This year the Chrome VRP also set some new records – 115 Chrome VRP researchers were rewarded for 333 unique Chrome security bug reports submitted in 2021, totaling $3.3 million in VRP rewards. The contributions not only help us to improve Chrome, but also the web at large by bolstering the security of all browsers based on Chromium.<br> Of the $3.3 million, $3.1 million was awarded for Chrome Browser security bugs and $250,500 for Chrome OS bugs, including a $45,000 top reward amount for an <a rel="noreferrer" target="_blank" href="https://crbug.com/1166932">individual Chrome OS security bug report</a> and $27,000 for an <a rel="noreferrer" target="_blank" href="https://crbug.com/1197904">individual Chrome Browser security bug report</a> .<br> Of these totals, $58,000 was awarded for security issues discovered by fuzzers contributed by VRP researchers to the <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/5745167867576320#:~:text=%245%2C000%20%2D%20%2415%2C000-,Chrome%20Fuzzer%20Program,-The%20Chrome%20Fuzzer">Chrome Fuzzing program</a> . Each valid report from an externally provided fuzzer received a $1,000 patch bonus, with <a rel="noreferrer" target="_blank" href="https://crbug.com/1242257">one fuzzer report</a> receiving a $16,000 reward.<br> The Chrome VRP would not be able to smash these records over the last year without the efforts of so many exceptional VRP researchers. We’d like to highlight a few researcher achievements made in 2021:<br> Rory McNamara, a Chrome OS VRP researcher who has been participating in the Chrome VRP for five years, became the highest awarded Chrome VRP researcher of all time. This year he was rewarded for six reports achieving root privilege escalation in Chrome OS, one of which received the highest reward amount achieved for a <a rel="noreferrer" target="_blank" href="https://crbug.com/1166932">single Chrome bug report</a> in 2021 at $45,000.<br> Chrome Browser VRP researcher Leecraso (@leecraso) of 360 Vulnerability Research Institute was the most awarded researcher of 2021, with 18 valid bug reports; a majority of which were for memory corruption vulnerabilities affecting the browser process.<br> We love when researchers write about their findings (only after we have publicly disclosed the bug, of course)! Chrome Browser VRP researcher Brendon Tiszka wrote an excellent two-part blog series on his <a rel="noreferrer" target="_blank" href="https://tiszka.com/blog/CVE_2021_21225.html">discovery</a> and <a rel="noreferrer" target="_blank" href="https://tiszka.com/blog/CVE_2021_21225_exploit.html">exploitation</a> of a V8 vulnerability, CVE-2021-21225, the analysis and reporting of which earned him a $22,000 VRP reward.<br> Huge thanks and congratulations to all Chrome VRP researchers that helped us make Chrome and Chrome OS more safe for all users in 2021!.<br> Google Play<br> Google Play paid out $550,000 in rewards to over 60 unique security researchers.<br> The Google Play Security Reward Program also <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/learn/presentations/5783688075542528">released their Android App Hacking Workshop content</a> and published a <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/12/empowering-next-generation-of-android.html">blog</a> on their work to empower the next generation of Android Application Security Researchers.<br> kCTF VRP<br> In November we <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/11/trick-treat-paying-leets-and-sweets-for.html">expanded</a> our reward amounts for exploits against our kCTF cluster from 5,000-10,000 up to 31,337-50,337 USD. In the last 3 months we were happy to have several participants receive $175,685 USD in rewards. We also extended the timeline of the increased rewards until February 14 (from January 31) which should give everyone a couple more weeks to finalize any almost-working exploits.<br> GCP VRP Prize<br> To encourage security researchers to focus on Google Cloud Platform, we initiated the annual GCP VRP Prize in 2019. In March this year, we <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/03/announcing-winners-of-2020-gcp-vrp-prize.html">announced</a> the winners of the 2020 edition of the prize and paid out $313,337 in prizes. Ezequiel Pereira won the top prize of $133,337 for finding an <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/report/reports/5105155099590656">RCE in Google Cloud Deployment Manager</a> . We saw some amazing research on Google Cloud Platform this year too. Stay tuned for the 2021 winners!<br> Research Grants<br> Six years ago, the Google VRP launched an experimental <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/5479188746993664">Vulnerability Research Grant program</a> to encourage seasoned security researchers to take a detailed and extensive look into the security of Google products and services. And reward them even if there are no vulnerabilities found. Six years later, we are happy to announce that in 2021 we awarded over $200,000 in grants to more than 120 security researchers around the world.<br> If you are a Google VRP researcher and want to be considered for a Vulnerability Research Grant make sure you opted in on your <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/">bughunters profile</a> .<br> Looking forward<br> With the launch of the new Bug Hunters portal, we plan to continue improving our platform and listening to you - our researchers - on ways we can improve our platform and Bug Hunter University.<br> Thank you again for making Google, the Internet, and our users safe and secure! Follow us on <a rel="noreferrer" target="_blank" href="http://twitter.com/googlevrp">@GoogleVRP</a><br> Thank you to Adam Bacchus, Dirk Göhmann, Sarah Jacobus, Amy Ressler, Martin Straka, Jan Keller, Jon Bottarini<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20220119-161455/ Wed, 19 Jan 2022 16:14:55 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20220119-161455/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2022/01/reducing-security-risks-in-open-source.html">Reducing Security Risks in Open Source Software at Scale: Scorecards Launches V4</a><br></p> <hr> Posted by Laurent Simon and Azeem Shaikh, Google Open Source Security Team (GOSST)<br> Since our <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/measuring-security-risks-in-open-source.html">July announcement</a> of Scorecards V2, the Scorecards project—an automated security tool to flag risky supply chain practices in open source projects—has grown steadily to over 40 unique contributors and 18 implemented security checks. Today we are proud to announce the V4 release of Scorecards, with larger scaling, a new security check, and a new Scorecards GitHub Action for easier security automation. The Scorecards Action is released in partnership with GitHub and is available from <a rel="noreferrer" target="_blank" href="https://github.com/marketplace/actions/ossf-scorecard-action">GitHub's Marketplace</a> . The Action makes using Scorecards easier than ever: it runs automatically on repository changes to alert developers about risky supply-chain practices. Maintainers can view the alerts on GitHub's <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/managing-code-scanning-alerts-for-your-repository">code scanning dashboard</a> , which is available for free to public repositories on GitHub.com and via GitHub Advanced Security for private repositories. Additionally, we have scaled our weekly Scorecards scans to over one million GitHub repositories, and have partnered with the <a rel="noreferrer" target="_blank" href="http://deps.dev/">Open Source Insights</a> website for easy user access to the data. For more details about the release, including the new Dangerous-Workflow security check, visit the OpenSSF's official blog post <a rel="noreferrer" target="_blank" href="https://security.googleblog.com">here</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211224-081323/ Fri, 24 Dec 2021 08:13:22 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211224-081323/ Editors Note:<br> The below numbers were calculated based on both log4j-core and log4j-api, as both were listed on the CVE. Since then, the CVE has been updated with the clarification that only log4j-core is affected.<br> The ecosystem impact numbers for just log4j-core, as of 19th December are over 17,000 packages affected, which is roughly 4% of the ecosystem. 25% of affected packages have fixed versions available. The <a rel="noreferrer" target="_blank" href="https://commondatastorage.googleapis.com/log4j_vulnerability/log4j_top_500_dependents.csv">linked list</a> , which continues to be updated, only includes packages which depend on log4j-core. ## More than 35,000 Java packages, amounting to over 8% of the <a rel="noreferrer" target="_blank" href="https://www.maven.org/">Maven Central repository</a> (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities ( <a rel="noreferrer" target="_blank" href="https://deps.dev/advisory/GHSA/GHSA-jfh8-c2jp-5v3q">1</a> , <a rel="noreferrer" target="_blank" href="https://deps.dev/advisory/GHSA/GHSA-7rjr-3q55-vv33">2</a> ), with widespread fallout across the software industry. The vulnerabilities allow an attacker to perform remote code execution by exploiting the insecure JNDI lookups feature exposed by the logging library log4j. This exploitable feature was enabled by default in many versions of the library.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211218-041425/ Sat, 18 Dec 2021 04:14:24 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211218-041425/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/12/apache-log4j-vulnerability.html">Apache Log4j Vulnerability</a><br></p> <hr> Like many other companies, we’re closely following the multiple CVEs regarding Apache Log4j 2. Our security teams are investigating any potential impact on Google products and services and are focused on protecting our users and customers. We encourage anyone who manages environments containing Log4j 2 to update to the <a rel="noreferrer" target="_blank" href="https://logging.apache.org/log4j/2.x/download.html">latest version</a> . Based on findings in our ongoing investigations, here is our list of product and service updates as of December 17th ( <a rel="noreferrer" target="_blank" href="https://nvd.nist.gov/vuln/detail/CVE-2021-44228">CVE-2021-44228</a> & <a rel="noreferrer" target="_blank" href="https://nvd.nist.gov/vuln/detail/CVE-2021-45046">CVE-2021-45046</a> ): Android is not aware of any impact to the Android Platform or Enterprise. At this time, no update is required for this specific vulnerability, but we encourage our customers to ensure that the latest security updates are applied to their devices. Chrome OS releases and infrastructure are not using versions of Log4j affected by the vulnerability. Chrome Browser releases, infrastructure and admin console are not using versions of Log4j affected by the vulnerability. Google Cloud has a <a rel="noreferrer" target="_blank" href="https://cloud.google.com/log4j2-security-advisory">specific advisory</a> dedicated to updating customers on the status of GCP and Workspace products and services. Google Marketing Platform, including Google Ads is not using versions of Log4j affected by the vulnerability. This includes Display & Video 360, Search Ads 360, Google Ads, Analytics (360 and free), Optimize 360, Surveys 360 & Tag Manager 360. YouTube is not using versions of Log4j affected by the vulnerability. We will continue to update this advisory with the latest information.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211217-201458/ Fri, 17 Dec 2021 20:14:57 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211217-201458/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html">Understanding the Impact of Apache Log4j Vulnerability</a><br></p> <hr> Posted by James Wetter and Nicky Ringland, Open Source Insights Team<br> More than 35,000 Java packages, amounting to over 8% of the <a rel="noreferrer" target="_blank" href="https://www.maven.org/">Maven Central repository</a> (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities ( <a rel="noreferrer" target="_blank" href="https://deps.dev/advisory/GHSA/GHSA-jfh8-c2jp-5v3q">1</a> , <a rel="noreferrer" target="_blank" href="https://deps.dev/advisory/GHSA/GHSA-7rjr-3q55-vv33">2</a> ), with widespread fallout across the software industry. The vulnerabilities allow an attacker to perform remote code execution by exploiting the insecure JNDI lookups feature exposed by the logging library log4j. This exploitable feature was enabled by default in many versions of the library.<br> This vulnerability has captivated the information security ecosystem since its disclosure on December 9th because of both its severity and widespread impact. As a popular logging tool, log4j is used by tens of thousands of software packages (known as artifacts in the Java ecosystem) and projects across the software industry. User’s lack of visibility into their dependencies and transitive dependencies has made patching difficult; it has also made it difficult to determine the full blast radius of this vulnerability. Using <a rel="noreferrer" target="_blank" href="https://deps.dev/">Open Source Insights</a> , a project to help understand open source dependencies, we surveyed all versions of all artifacts in the <a rel="noreferrer" target="_blank" href="https://www.maven.org/">Maven Central Repository</a> to determine the scope of the issue in the open source ecosystem of JVM based languages, and to track the ongoing efforts to mitigate the affected packages.<br> How widespread is the log4j vulnerability?<br> As of December 16, 2021, we found that 35,863 of the available Java artifacts from Maven Central depend on the affected log4j code. This means that more than 8% of all packages on Maven Central have at least one version that is impacted by this vulnerability. (These numbers do not encompass all Java packages, such as directly distributed binaries, but Maven Central is a strong proxy for the state of the ecosystem.) As far as ecosystem impact goes, 8% is enormous. The average ecosystem impact of advisories affecting Maven Central is 2%, with the median less than 0.1%.<br> Direct dependencies account for around 7,000 of the affected artifacts, meaning that any of its versions depend upon an affected version of log4j-core or log4j-api, as described in the CVEs. The majority of affected artifacts come from indirect dependencies (that is, the dependencies of one’s own dependencies), meaning log4j is not explicitly defined as a dependency of the artifact, but gets pulled in as a transitive dependency.<br> What is the current progress in fixing the open source JVM ecosystem? We counted an artifact as fixed if the artifact had at least one version affected and has released a greater stable version (according to <a rel="noreferrer" target="_blank" href="http://semver.org/">semantic</a> versioning) that is unaffected. An artifact affected by log4j is considered fixed if it has updated to 2.16.0 or removed its dependency on log4j altogether. At the time of writing, nearly five thousand of the affected artifacts have been fixed. This represents a rapid response and mammoth effort both by the log4j maintainers and the wider community of open source consumers. That leaves over 30,000 artifacts affected, many of which are dependent on another artifact to patch (the transitive dependency) and are likely blocked.<br> Why is fixing the JVM ecosystem hard?<br> Most artifacts that depend on log4j do so indirectly. The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs. F or greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.<br> Another difficulty is caused by ecosystem-level choices in the dependency resolution algorithm and requirement specification conventions. In the Java ecosystem, it’s common practice to specify “ <a rel="noreferrer" target="_blank" href="https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification">soft</a> ” version requirements — exact versions that are used by the resolution algorithm if no other version of the same package appears earlier in the dependency graph. Propagating a fix often requires explicit action by the maintainers to update the dependency requirements to a patched version. This practice is in contrast to other ecosystems, such as npm, where it’s common for developers to specify open ranges for dependency requirements. Open ranges allow the resolution algorithm to select the most recently released version that satisfies dependency requirements, thereby pulling in new fixes. Consumers can get a patched version on the next build after the patch is available, which propagates up the dependencies quickly. (This approach is not without its drawbacks; pulling in new fixes can also pull in new problems.)<br> How long will it take for this vulnerability to be fixed across the entire ecosystem?<br> It’s hard to say. We looked at all publicly disclosed critical advisories affecting Maven packages to get a sense of how quickly other vulnerabilities have been fully addressed. Less than half (48%) of the artifacts affected by a vulnerability have been fixed, so we might be in for a long wait, likely years. But things are looking promising on the log4j front. After less than a week, 4,620 affected artifacts (~13%) have been fixed. This, more than any other stat, speaks to the massive effort by open source maintainers, information security teams and consumers across the globe.<br> Where to focus next?<br> Thanks and congratulations are due to the open source maintainers and consumers who have already upgraded their versions of log4j. As part of our investigation, we pulled together <a rel="noreferrer" target="_blank" href="https://commondatastorage.googleapis.com/log4j_vulnerability/log4j_top_500_dependents.csv">a list</a> of 500 affected packages with some of the highest transitive usage. If you are a maintainer or user helping with the patching effort, prioritizing these packages could maximize your impact and unblock more of the community. We encourage the open source community to continue to strengthen security in these packages by enabling automated dependency updates and adding security mitigations. Improvements such as these could qualify for financial rewards from the <a rel="noreferrer" target="_blank" href="https://sos.dev/">Secure Open Source Rewards program</a> . You can explore your package dependencies and their vulnerabilities by using <a rel="noreferrer" target="_blank" href="https://deps.dev/">Open Source Insights</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211217-001458/ Fri, 17 Dec 2021 00:14:58 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211217-001458/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/12/improving-oss-fuzz-and-jazzer-to-catch.html">Improving OSS-Fuzz and Jazzer to catch Log4Shell</a><br></p> <hr> The discovery of the <a rel="noreferrer" target="_blank" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228">Log4Shell vulnerability</a> has set the internet on fire. Similar to <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Shellshock_(software_bug)">shellshock</a> and <a rel="noreferrer" target="_blank" href="https://heartbleed.com/">heartbleed</a> , Log4Shell is just the latest catastrophic vulnerability in <a rel="noreferrer" target="_blank" href="https://github.com/NCSC-NL/log4shell/tree/main/software">software that runs the internet</a> . Our mission as the Google Open Source Security Team is to secure the open source libraries the world depends on, such as Log4j. One of our capabilities in this space is OSS-Fuzz, a free fuzzing service that is used by over 500 critical open source projects and has found more than <a rel="noreferrer" target="_blank" href="https://bugs.chromium.org/p/oss-fuzz/issues/list?q=type%3Dbug-security%20-status%3Aduplicate%2Cwontfix&can=1">7,000 vulnerabilities</a> in its lifetime. We want to empower open source developers to secure their code on their own. Over the next year we will work on better automated detection of non-memory corruption vulnerabilities such as Log4Shell. We have started this work by partnering with the security company <a rel="noreferrer" target="_blank" href="https://www.code-intelligence.com/">Code Intelligence</a> to <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-fuzz/pull/7016">provide continuous fuzzing for Log4j</a> , as part of OSS-Fuzz. Also as part of this partnership, Code-Intelligence improved their <a rel="noreferrer" target="_blank" href="https://github.com/CodeIntelligenceTesting/jazzer">Jazzer fuzzing engine</a> to make it <a rel="noreferrer" target="_blank" href="https://github.com/CodeIntelligenceTesting/jazzer/blob/3fed476bed7c61370e12062b5b97a939e3c5e591/sanitizers/src/main/java/com/code_intelligence/jazzer/sanitizers/NamingContextLookup.kt#L90">capable of detecting remote JNDI lookups</a> . We have awarded Code Intelligence $25,000 for this effort and will continue to work with them on securing the open source ecosystem.<br> Caption: OSS-Fuzz and Jazzer finding the Log4Shell Vulnerability<br> Vulnerabilities like Log4Shell are an eye-opener for the industry in terms of new attack vectors. With OSS-Fuzz and Jazzer, we can now detect this class of vulnerability so that they can be fixed before they become a problem in production code. Over the past year we have made a number of investments to strengthen the security of critical open source projects, and recently announced our $ <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/why-were-committing-10-billion-to-advance-cybersecurity/">10 billion commitment to cybersecurity</a> defense including $100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities. We appreciate the maintainers, security engineers and incident responders that are working to mitigate Log4j and make our internet ecosystem safer. Check out <a rel="noreferrer" target="_blank" href="https://google.github.io/oss-fuzz/getting-started/new-project-guide/jvm-lang/">our documentation</a> to get started using OSS-Fuzz.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211214-201504/ Tue, 14 Dec 2021 20:15:03 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211214-201504/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/12/empowering-next-generation-of-android.html">Empowering the next generation of Android Application Security Researchers</a><br></p> <hr> Posted by Jon Bottarini, Security Program Manager & Lena Katib, Strategic Partnerships Manager<br> The external security researcher community plays an integral role in making the Google Play ecosystem safe and secure. Through this partnership with the community, Google has been able to collaborate with third-party developers to fix thousands of security issues in Android applications before they are exploited and reward security researchers for their hard work and dedication.<br> In order to empower the next generation of Android security researchers, Google has collaborated with industry partners including <a rel="noreferrer" target="_blank" href="https://www.hackerone.com/">HackerOne</a> and PayPal to host a number of Android App Hacking Workshops. These workshops are an effort designed to educate security researchers and cybersecurity students of all skill levels on how to find Android application vulnerabilities through a series of hands-on working sessions, both in-person and virtual.<br> Through these workshops, we’ve seen attendees from groups such as <a rel="noreferrer" target="_blank" href="https://merrittsecurity.com/">Merritt College's cybersecurity program</a> and alumni of <a rel="noreferrer" target="_blank" href="https://www.hackthehood.org/">Hack the Hood</a> go on to report real-world security vulnerabilities to the <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/5604090422493184">Google Play Security Rewards program</a> . This reward program is designed to identify and mitigate vulnerabilities in apps on Google Play, and keep Android users, developers and the Google Play ecosystem safe.<br> Today, we are releasing our slide deck and workshop materials, including source code for a custom-built Android application that allows you to test your Android application security skills in a variety of capture the flag style challenges.<br> These materials cover a wide range of techniques for finding vulnerabilities in Android applications. Whether you’re just getting started or have already found many bugs - chances are you’ll learn something new from these challenges! If you get stuck and need a hint on solving a challenge, the solutions for each are available in the Android App Hacking Workshop <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/learn/presentations/5783688075542528">here</a> .<br> As you work through the challenges and learn more about the techniques and tips described in our workshop materials, we’d love to <a rel="noreferrer" target="_blank" href="https://forms.gle/DUA1tNpaLCLR21h87">hear your feedback</a> .<br> Additional Resources:<br> If you want to learn more about how to prepare, launch, and run a Vulnerability Disclosure Program (VDP) or discover how to work with external security researchers, check out our VDP course <a rel="noreferrer" target="_blank" href="https://security.googleblog.com">here</a> .<br> If you’re a developer looking to build more secure applications, check out Android app security best practices <a rel="noreferrer" target="_blank" href="https://developer.android.com/topic/security/best-practices">here</a> .<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android">android</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/google%20play">google play</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/hacking">hacking</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/security%20rewards%20program">security rewards program</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/VDP">VDP</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/workshop">workshop</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211202-201606/ Thu, 02 Dec 2021 20:16:06 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211202-201606/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/12/exploring-container-security-storage.html">Exploring Container Security: A Storage Vulnerability Deep Dive</a><br></p> <hr> Posted by Fabricio Voznika and Mauricio Poppe, Google Cloud Kubernetes Security is constantly evolving - keeping pace with enhanced functionality, usability and flexibility while also balancing the security needs of a wide and diverse set of use-cases. Recently, the GKE Security team discovered a <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2021-018">high severity vulnerability</a> that allowed workloads to have access to parts of the host filesystem outside the mounted volumes boundaries. Although the vulnerability was patched back in September we thought it would be beneficial to write up a more in-depth analysis of the issue to share with the community. We assessed the impact of the vulnerability as described in <a rel="noreferrer" target="_blank" href="https://cloud.google.com/blog/products/containers-kubernetes/exploring-container-security-vulnerability-management-in-open-source-kubernetes">vulnerability management in open-source Kubernetes</a> and worked closely with the GKE Storage team and <a rel="noreferrer" target="_blank" href="https://github.com/kubernetes/committee-security-response">the Kubernetes Security Response Committee</a> to find a fix. In this post we’ll give some background on how the subpath storage system works, an overview of the vulnerability, the steps to find the root cause and the fix, and finally some recommendations for GKE and Anthos users. Kubernetes Filesystems: Intro to Volume Subpath The vulnerability, <a rel="noreferrer" target="_blank" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25741">CVE-2021-25741,</a> was caused by a race condition during the creation of a subpath bind mount <a rel="noreferrer" target="_blank" href="https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath">inside a container, and</a> allowed an attacker to gain unauthorized access to the underlying node filesystem and its sensitive files. We’ll describe how that system is supposed to work, and then talk about the vulnerability. The <a rel="noreferrer" target="_blank" href="https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath">volume subpath</a> feature in Kubernetes enables sharing a volume in multiple containers inside a pod. For example, we could create a Pod with an InitContainer that creates directories with pre-populated data in a mounted filesystem volume. These directories can then be used by containers in the same Pod by mounting the same volume and optionally specifying a subpath field to limit what's visible inside the container. While there are some great use cases for this feature, it’s an area that has had vulnerabilities discovered in the past. The kubelet must be extra cautious when handling user-owned subpaths because it operates with privileges in the host. One vulnerability that has been previously discovered involved the creation of a malicious workload where an InitContainer would create a symlink pointing to any location in the host. For example, the InitContainer could mount a volume in /mnt and create a symlink /mnt/attack inside the container pointing to /etc. Later in the Pod lifecycle, another container would attempt to mount the same volume with subpath attack. While preparing the volumes for the container, the kubelet would end up following the symlink to the host’s /etc instead of the container’s /etc, unknowingly exposing the host filesystem to the container. <a rel="noreferrer" target="_blank" href="https://kubernetes.io/blog/2018/04/04/fixing-subpath-volume-vulnerability/">A previous fix</a> made sure that the subpath mount location is resolved and validated to point to a location inside the base volume and that it's not changeable by the user in between the time the path was validated and when the container runtime bind mounts it. This race condition is known as <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use">time of check to time of use (TOCTOU)</a> where the subject being validated changes after it has been validated. These validations and others are summarized in the following container lifecycle sequence diagram. Volume subpath validations before the container startup A New TOCTOU Vulnerability: CVE-2021-25741 The latest vulnerability was discovered by performing a symlink attack similar to the one explained above, with the difference being that it constantly swapped the symlink with a directory in a tight loop, using the RENAME_EXCHANGE option with <a rel="noreferrer" target="_blank" href="https://man7.org/linux/man-pages/man2/rename.2.html">renameat(2)</a> . If the timing is just right, the kubelet will see the path as a directory and pass the validation check. Then the mount utility may find that the path is a symlink pointing to the host and follow it, exposing the host filesystem to the container. This is visualized in the following diagram:<br> The expectation and the attack outcome<br> The GKE Security and Storage teams worked closely to revise the fix done previously to find a solution. The previous fix takes several steps to ensure that the directory being mounted is safely opened and validated. After the file is opened and validated, the kubelet uses the magic-link path under /proc/[pid]/fd directory for all subsequent operations to ensure the file remains unchanged. However, we found out that all of the efforts were undone by the <a rel="noreferrer" target="_blank" href="https://man7.org/linux/man-pages/man8/mount.8.html">mount(8)</a> linux utility which was dereferencing the procfs magic-link by default. Once the problem was understood, the fix involved making sure that the mount utility doesn't dereference the magic-links by using the --no-canonicalize flag in the mount command. The fix is in<br> Once the problem was well understood, we fixed it inside Kubernetes and quickly <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2021-018">released the fix to GKE and Anthos</a> . If GKE auto-upgrade is enabled in your clusters there's no action on your part for this vulnerability, your nodes have already been patched. We strongly recommend that customers utilize <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-upgrades">auto-upgrades</a> . Auto-upgrade gives peace of mind that your clusters are running with the latest patches. GKE released a <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2021-018">Google Kubernetes Engine security bulletin</a> on this vulnerability, which detailed what customers can do to immediately remediate this issue across GKE and Anthos. We also provided guidance to customers who manually manage their node versions, ensuring that fixed releases were available in every region for our <a rel="noreferrer" target="_blank" href="https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels">Static and Release Channels</a> . Moving forward Google continues to invest heavily in the security of GKE and Kubernetes. We encourage users interested in finding vulnerabilities to participate in the <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/01/securing-open-source-how-google.html">Kubernetes bug bounty program</a> and in the <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/05/expanding-our-work-with-open-source.html">Google Vulnerability Rewards Program (VRP)</a> which was recently expanded to cover GKE vulnerabilities. For the latest guidance on security issues, please follow our <a rel="noreferrer" target="_blank" href="https://cloud.google.com/anthos/clusters/docs/security-bulletins">GKE Security Bulletins</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211111-201451/ Thu, 11 Nov 2021 20:14:51 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211111-201451/ To learn more, check out the <a rel="noreferrer" target="_blank" href="https://google.github.io/clusterfuzzlite/">ClusterFuzzLite documentation</a> . ClusterFuzzLite currently supports <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions">GitHub Actions</a> , <a rel="noreferrer" target="_blank" href="https://cloud.google.com/build">Google Cloud Build</a> and <a rel="noreferrer" target="_blank" href="https://github.com/kubernetes/test-infra/tree/master/prow#readme">Prow</a> . We built this with CI system extensibility in mind, and adding support for other CI systems is straightforward. Please <a rel="noreferrer" target="_blank" href="https://github.com/google/clusterfuzzlite/issues/new">contact us</a> if you’re interested in contributing support, or have any questions, feedback or feature requests.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211111-121632/ Thu, 11 Nov 2021 12:16:32 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211111-121632/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/11/clusterfuzzlite-continuous-fuzzing-for.html">ClusterFuzzLite: Continuous fuzzing for all</a><br></p> <hr> Posted by Jonathan Metzman, Google Open Source Security Team<br> In recent years, <a rel="noreferrer" target="_blank" href="https://github.com/google/fuzzing/blob/master/docs/intro-to-fuzzing.md">continuous fuzzing</a> has become an essential part of the software development lifecycle. By feeding unexpected or random data into a program, fuzzing catches bugs that would otherwise slip through the most thorough manual checks and provides coverage that would take staggering human effort to replicate. <a rel="noreferrer" target="_blank" href="https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/recommended-minimum-standards-vendor-or">NIST’s guidelines for software verification</a> , recently released in response to the White House <a rel="noreferrer" target="_blank" href="https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/">Executive Order on Improving the Nation’s Cybersecurity</a> , specify fuzzing among the minimum standard requirements for code verification. Today, we are excited to announce <a rel="noreferrer" target="_blank" href="https://github.com/google/clusterfuzzlite">ClusterFuzzLite</a> , a continuous fuzzing solution that runs as part of CI/CD workflows to find vulnerabilities faster than ever before. With just a few lines of code, GitHub users can integrate ClusterFuzzLite into their workflow and fuzz pull requests to catch bugs before they are committed, enhancing the overall security of the software supply chain. Since its release in 2016, over 500 critical open source projects have integrated into Google’s <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html">OSS-Fuzz</a> program, resulting in over <a rel="noreferrer" target="_blank" href="https://bugs.chromium.org/p/oss-fuzz/issues/list?q=Type%3DBug-Security%20status%3AVerified&can=1">6,500</a> vulnerabilities and <a rel="noreferrer" target="_blank" href="https://bugs.chromium.org/p/oss-fuzz/issues/list?q=Type%3DBug%20status%3AVerified%20-Type%3DBug-Security&can=1">21,000</a> functional bugs being fixed. ClusterFuzzLite goes hand-in-hand with OSS-Fuzz, by catching regression bugs much earlier in the development process. Large projects including <a rel="noreferrer" target="_blank" href="https://github.com/systemd/systemd/actions/workflows/cifuzz.yml">systemd</a> and <a rel="noreferrer" target="_blank" href="https://github.com/curl/curl/actions/workflows/fuzz.yml">curl</a> are already using ClusterFuzzLite during code review, with positive results. According to Daniel Stenberg, author of curl, “When the human reviewers nod and have approved the code and your static code analyzers and linters can't detect any more issues, fuzzing is what takes you to the next level of code maturity and robustness. OSS-Fuzz and ClusterFuzzLite help us maintain curl as a quality project, around the clock, every day and every commit.” With the release of ClusterFuzzLite, any project can integrate this essential testing standard and benefit from fuzzing. ClusterFuzzLite offers many of the same features as <a rel="noreferrer" target="_blank" href="https://github.com/google/clusterfuzz">ClusterFuzz</a> , such as continuous fuzzing, sanitizer support, corpus management, and coverage report generation. Most importantly, it’s easy to set up and works with closed source projects, making ClusterFuzzLite a convenient option for any developer who wants to fuzz their software.<br> With ClusterFuzzLite, fuzzing is no longer just an idealized "bonus" round of testing for those who have access to it, but a critical must-have step that everyone can use continuously on every software project. By finding and preventing bugs before they enter the codebase we can build a more secure software ecosystem.<br> To learn more, check out the <a rel="noreferrer" target="_blank" href="https://google.github.io/clusterfuzzlite/">ClusterFuzzLite documentation</a> . ClusterFuzzLite currently supports <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/actions">GitHub Actions</a> and <a rel="noreferrer" target="_blank" href="https://cloud.google.com/build">Google Cloud Build</a> . We built this with CI system extensibility in mind, and adding support for other CI systems is straightforward. Please <a rel="noreferrer" target="_blank" href="https://github.com/google/clusterfuzzlite/issues/new">contact us</a> if you’re interested in contributing support, or have any questions, feedback or feature requests.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211102-001836/ Tue, 02 Nov 2021 00:18:35 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211102-001836/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/11/trick-treat-paying-leets-and-sweets-for.html">Trick & Treat! 🎃 Paying Leets and Sweets for Linux Kernel privescs and k8s escapes</a><br></p> <hr> Posted by Eduardo Vela, Google Bug Hunters Team Starting today and for the next 3 months (until January 31 2022), we will pay 31,337 USD to security researchers that exploit privilege escalation in our lab environment with a patched vulnerability, and 50,337 USD to those that use a previously unpatched vulnerability, or a new exploit technique. We are constantly investing in the security of the Linux Kernel because much of the internet, and Google—from the devices in our pockets, to the services running on <a rel="noreferrer" target="_blank" href="https://kubernetes.io/">Kubernetes</a> in the cloud—depend on the security of it. We <a rel="noreferrer" target="_blank" href="https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html">research its vulnerabilities and attacks</a> , as well as <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html">study and develop its defenses</a> . But we know that there is more work to do. That’s why we have decided to build on top of our <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/05/expanding-our-work-with-open-source.html">kCTF VRP</a> from last year and triple our previous reward amounts (for at least the next 3 months). Our base rewards for each publicly patched vulnerability is 31,337 USD (at most one exploit per vulnerability), but the reward can go up to 50,337 USD in two cases:<br> If the vulnerability was otherwise unpatched in the Kernel (0day)<br> If the exploit uses a new attack or technique, as determined by Google<br> We hope the new rewards will encourage the security community to explore new Kernel exploitation techniques to achieve privilege escalation and drive quicker fixes for these vulnerabilities. It is important to note, that the easiest exploitation primitives are not available in our lab environment due to the hardening done on <a rel="noreferrer" target="_blank" href="https://cloud.google.com/container-optimized-os/docs">Container-Optimized OS</a> . Note this program complements Android's VRP rewards, so exploits that work on Android could also be eligible for up to <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/6171833274204160">250,000 USD</a> (that's in addition to this program). The mechanics are:<br> Connect to the <a rel="noreferrer" target="_blank" href="https://google.github.io/kctf/vrp">kCTF VRP cluster</a> , obtain root and read the flag (read <a rel="noreferrer" target="_blank" href="https://github.com/google/security-research/blob/master/pocs/linux/cve-2021-22555/writeup.md">this writeup</a> for how it was done before, and <a rel="noreferrer" target="_blank" href="https://google.github.io/kctf/security-threat-model.html">this threat model</a> for inspiration), and then submit your flag and a checksum of your exploit <a rel="noreferrer" target="_blank" href="https://docs.google.com/forms/d/e/1FAIpQLSeQf6aWmIIjtG4sbEKfgOBK0KL3zzeHCrsgA1EcPr-xsFAk7w/viewform">in this form</a> .<br> (If applicable) report vulnerabilities to <a rel="noreferrer" target="_blank" href="https://github.com/google/kctf/blob/v1/SECURITY.md">upstream</a> .<br> We strongly recommend including a patch since that could qualify for an <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/patch-rewards">additional reward</a> from our Patch Reward Program, but please report vulnerabilities upstream promptly once you confirm they are exploitable.<br> <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/report/vrp">Report your finding</a> to Google VRP once all patches are publicly available (we don't want to receive details of unpatched vulnerabilities ahead of the public.)<br> Provide the exploit code and the algorithm used to calculate the hash checksum.<br> A rough description of the exploit strategy is welcome.<br> Reports will be triaged on a weekly basis. If anyone has problems with the lab environment (if it's unavailable, technical issues or other questions), contact us on Discord in <a rel="noreferrer" target="_blank" href="https://discord.gg/V8UqnZ6JBG">#kctf</a> . You can read more details about the program <a rel="noreferrer" target="_blank" href="https://google.github.io/kctf/vrp">here</a> . Happy hunting!<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211030-015855/ Sat, 30 Oct 2021 01:58:55 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211030-015855/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/10/protecting-your-device-information-with.html">Protecting your device information with Private Set Membership</a><br></p> <hr> Posted by Kevin Yeo and Sarvar Patel, Private Computing Team<br> At Google, keeping you safe online is our top priority, so we continuously build the most advanced privacy-preserving technologies into our products. Over the past few years, we've utilized innovations in cryptographic research to keep your personal information private by design and secure by default. As part of this, we launched <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2019/02/protect-your-accounts-from-data.html">Password Checkup</a> , which protects account credentials by notifying you if an entered username and password are known to have been compromised in a prior data breach. Using cryptographic techniques, Password Checkup can do this without revealing your credentials to anyone, including Google. Today, Password Checkup protects users across many platforms including <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/02/new-password-checkup-feature-coming-to.html">Android</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html">Chrome</a> and <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/password-checkup/">Google Password Manager</a> . Another example is <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2019/06/helping-organizations-do-more-without-collecting-more-data.html">Private Join and Compute</a> , an open source protocol which enables organizations to work together and draw insights from confidential data sets. Two parties are able to encrypt their data sets, join them, and compute statistics over the joint data. By leveraging secure multi-party computation, Private Join and Compute is designed to ensure that the plaintext data sets are concealed from all parties. In this post, we introduce the next iteration of our research, Private Set Membership, as well as its <a rel="noreferrer" target="_blank" href="https://github.com/google/private-membership">open-source availability</a> . At a high level, Private Set Membership considers the scenario in which Google holds a database of items, and user devices need to contact Google to check whether a specific item is found in the database. As an example, users may want to check membership of a computer program on a block list consisting of known malicious software before executing the program. Often, the set’s contents and the queried items are sensitive, so we designed Private Set Membership to perform this task while preserving the privacy of our users. Protecting your device information during enrollment Beginning in Chrome 94, Private Set Membership will enable Chrome OS devices to complete the enrollment process in a privacy-preserving manner. Device enrollment is an integral part of the out-of-box experience that welcomes you when getting started with a Chrome OS device. The device enrollment process requires checking membership of device information in encrypted Google databases, including checking if a device is enterprise enrolled or determining if a device was pre-packaged with a license. The correct end state of your Chrome OS device is determined using the results of these membership checks. During the enrollment process, we protect your Chrome OS devices by ensuring no information ever leaves the device that may be decrypted by anyone else when using Private Set Membership. Google will never learn any device information and devices will not learn any unnecessary information about other devices. ​​To our knowledge, this is the first instance of advanced cryptographic tools being leveraged to protect device information during the enrollment process. A deeper look at Private Set Membership Private Set Membership is built upon two cryptographic tools:<br> Homomorphic encryption is a powerful cryptographic tool that enables computation over encrypted data without the need for decryption. As an example, given the encryptions of values X and Y, homomorphic encryption enables computing the encryption of the sum of X and Y without ever needing to decrypt. This preserves privacy as the data remains concealed during the computation. Private Set Membership is built upon Google’s <a rel="noreferrer" target="_blank" href="https://github.com/google/shell-encryption">open source</a> homomorphic encryption library.<br> Oblivious hashing is a cryptographic technique that enables two parties to jointly compute a hash, H(K, x), where the sender holds the key, K, and the receiver holds the hash input, x. The receiver will obtain the hash, H(K, x), without learning the key K. At the same time, the input x will be hidden from the sender.<br> Take a look at how Private Set Membership utilizes homomorphic encryption and oblivious hashing to protect data below:<br> For a deeper look into the technology behind Private Set Membership, you can also <a rel="noreferrer" target="_blank" href="https://github.com/google/private-membership">access our open source code</a> . Privacy properties By using Private Set Membership, the following privacy properties are obtained:<br> No data leaves the device when checking membership. We designed Private Set Membership using advanced cryptographic techniques to ensure that data never leaves the device in an unencrypted manner when performing membership checks. As a result, the data on your device will be concealed from everyone, including Google.<br> Devices learn only membership information and nothing else. Private Set Membership was designed to prevent devices from learning any unnecessary information about other devices when querying. For each query, devices learn only the results of the membership check and no other information.<br> Using Private Set Membership to solve more problems Private Set Membership is a powerful tool that solves a fundamental problem in a privacy-preserving manner. This is just the beginning of what’s possible using this technology. Private Set Membership can help preserve user privacy across a wide array of applications. For example:<br> Checking allow or block lists. In this setting, users check membership in an allow or block list to determine whether to proceed with the desired action. Private Set Membership enables this check without any information about the software leaving the device.<br> Control flows with conditional membership checks. Control flows are a common computer science concept that represent arbitrary computer programs with conditional branching. In many cases, the conditional branches require checking membership of sensitive data to determine the next step of the algorithm. By utilizing Private Set Membership, we enable execution of these algorithms while ensuring data never leaves the user’s device.<br> We still have a ways to go before Private Set Membership is used for general membership checks by devices. At Google, we are exploring a number of potential use cases to protect your privacy using Private Set Membership. We are excited to continue advancing the state-of-the-art cryptographic research to keep you safe. Acknowledgements The work in this post is the result of a collaboration between a large group of current and former Google engineers, research scientists and others including: Amr Aboelkher, Asra Ali, Ghous Amjad, Yves Arrouye, Roland Bock, Xi Chen, Maksim Ivanov, Dennis Kalinichenko, Nirdhar Khazanie, Dawon Lee, Tancrède Lepoint, Lawrence Lui, Pavol Marko, Thiemo Nagel, Mariana Raykova, Aaron Segal, Joon Young Seo, Karn Seth, and Jason Wong.<br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/10/pixel-6-setting-new-standard-for-mobile.html">Pixel 6: Setting a new standard for mobile security</a><br> <hr> Posted by Dave Kleidermacher, Jesse Seed, Brandon Barbello, and Stephan Somogyi, Android, Pixel & Tensor security teams<br> With Pixel 6 and Pixel 6 Pro, we’re launching our most secure Pixel phone yet, with <a rel="noreferrer" target="_blank" href="https://support.google.com/pixelphone/answer/4457705?p=pixel_android_updates&visit_id=637708689245917155-1925669063&rd=1">5 years of security updates</a> and the most layers of hardware security. These new Pixel smartphones take a layered security approach, with innovations spanning across the <a rel="noreferrer" target="_blank" href="https://blog.google/products/pixel/introducing-google-tensor/">Google Tensor</a> system on a chip (SoC) hardware to new Pixel-first features in the Android operating system, making it the first Pixel phone with Google security from the silicon all the way to the data center. Multiple dedicated security teams have also worked to ensure that Pixel’s security is provable through transparency and external validation.<br> Secure to the Core<br> Google has put user data protection and transparency at the forefront of hardware security with Google Tensor. Google Tensor’s main processors are Arm-based and utilize <a rel="noreferrer" target="_blank" href="https://developer.arm.com/ip-products/security-ip/trustzone">TrustZone</a> ™ technology. TrustZone is a key part of our security architecture for general secure processing, but the security improvements included in Google Tensor go beyond TrustZone.<br> Figure 1. Pixel Secure Environments<br> The Google Tensor security core is a custom designed security subsystem dedicated to the preservation of user privacy. It's distinct from the application processor, not only logically, but physically, and consists of a dedicated CPU, ROM, one-time-programmable (OTP) memory, crypto engine, internal SRAM, and protected DRAM. For Pixel 6 and 6 Pro, the security core’s primary use cases include protecting user data keys at runtime, hardening secure boot, and interfacing with Titan M2 TM .<br> Your secure hardware is only as good as your secure OS, and we are using <a rel="noreferrer" target="_blank" href="https://source.android.com/security/trusty">Trusty</a> , our open source trusted execution environment. Trusty OS is the secure OS used both in TrustZone and the Google Tensor security core.<br> With Pixel 6 and Pixel 6 Pro your security is enhanced by the new Titan M2 TM , our discrete security chip, fully designed and developed by Google. In this next generation chip, we moved to an in-house designed RISC-V processor, with extra speed and memory, and made it even more resilient to advanced attacks. Titan M2 TM has been tested against the most rigorous standard for vulnerability assessment, AVA_VAN.5, by an independent, accredited evaluation lab. Titan M2™ supports <a rel="noreferrer" target="_blank" href="https://developer.android.com/training/articles/keystore#HardwareSecurityModule">Android Strongbox</a> , which securely generates and stores keys used to protect your PINs and password, and works hand-in-hand with Google Tensor security core to protect user data keys while in use in the SoC.<br> Moving a step higher in the system, Pixel 6 and Pixel 6 Pro ship with <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2021/10/android-12-is-live-in-aosp.html">Android 12</a> and a slew of Pixel-first and Pixel-exclusive features.<br> Enhanced Controls<br> We aim to give users better ways to control their data and manage their devices with every release of Android. Starting with Android 12 on Pixel, you can use the new Security hub to manage all your security settings in one place. It helps protect your phone, apps, Google Account, and passwords by giving you a central view of your device’s current configuration. Security hub also provides recommendations to improve your security, helping you decide what settings best meet your needs.<br> For privacy, we are launching Privacy Dashboard, which will give you a … https://www.whatsupup.com/blog/ewing/undiscernibly/20211005-201726/ Tue, 05 Oct 2021 20:17:25 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211005-201726/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/10/google-protects-your-accounts-even-when.html">Google Protects Your Accounts – Even When You No Longer Use Them</a><br></p> <hr> Posted by Sam Heft-Luthy, Product Manager, Privacy & Data Protection Office What happens to our digital accounts when we stop using them? It’s a question we should all ask ourselves, because when we are no longer keeping tabs on what’s happening with old accounts, they can become targets for cybercrime. In fact, quite a few recent high-profile breaches targeted inactive accounts. The <a rel="noreferrer" target="_blank" href="https://www.crn.com/news/security/colonial-pipeline-hacked-via-inactive-account-without-mfa">Colonial Pipeline</a> ransomware attack came through an inactive account that didn’t use multifactor authentication, according to a consultant who investigated the incident. And in the case of the recent <a rel="noreferrer" target="_blank" href="https://techcrunch.com/2021/08/18/t-mobile-says-at-least-47m-current-and-former-customers-affected-by-data-breach/">T-Mobile breach</a> this summer, information from inactive prepaid accounts was accessed through old billing files. Inactive accounts can pose a serious security risk. For Google users, <a rel="noreferrer" target="_blank" href="https://support.google.com/accounts/answer/3036546?hl=en">Inactive Account Manager</a> helps with that problem. You can decide when Google should consider your account inactive and whether Google should delete your data or share it with a trusted contact.<br> Here’s How it Works<br> Once you <a rel="noreferrer" target="_blank" href="https://myaccount.google.com/inactive">sign up</a> for Inactive Account Manager, available in My Account settings, you are asked to decide three things:<br> When the account should be considered inactive: You can choose 3, 6, 12 or 18 months of inactivity before Google takes action on your account. Google will notify you a month before the designated time via a message sent to your phone and an email sent to the address you provide.<br> Who to notify and what to share: You can choose up to 10 people for Google to notify once your Google Account becomes inactive (they won’t be notified during setup). You can also give them access to some of your data. If you choose to share data with your trusted contacts, the email will include a list of the selected data you wanted to share with them, and a link they can follow to download that data. This can include things like photos, contacts, emails, documents and other data that you specifically choose to share with your trusted contact. You can also choose to set up a Gmail AutoReply, with a custom subject and message explaining that you’ve ceased using the account.<br> If your inactive Google Account should be deleted: After your account becomes inactive, Google can delete all its content or send it to your designated contacts. If you’ve decided to allow someone to download your content, they’ll be able to do so for 3 months before it gets deleted. If you choose to delete your Google Account, this will include your publicly shared data (for example, your YouTube videos, or blogs on Blogger). You can review the data associated with your account on the <a rel="noreferrer" target="_blank" href="https://myaccount.google.com/dashboard">Google Dashboard</a> . If you use Gmail with your account, you'll no longer be able to access that email once your account becomes inactive. You'll also be unable to reuse that Gmail username.<br> Setting up an Inactive Account plan is a simple step you can take to protect your data, secure your account in case it becomes inactive, and ensure that your digital legacy is shared with your trusted contacts in case you become unable to access your account. Our <a rel="noreferrer" target="_blank" href="https://myaccount.google.com/intro/privacycheckup?hl=en">Privacy Checkup</a> now reminds you to set up a plan for your account, and we’ll send you an occasional reminder about your plan via email. At Google, we are constantly working to keep you safer online. This October, as we celebrate Cybersecurity Awareness Month, we want to remind our users of the security and privacy controls they have at their fingertips. For more ways to enhance your security check out our <a rel="noreferrer" target="_blank" href="https://safety.google/security/security-tips/">top five safety tips</a> and visit our <a rel="noreferrer" target="_blank" href="https://safety.google/?utm_medium=blogpost&utm_source=google&utm_campaign=sid2021">Safety Center</a> to learn all the ways Google helps keep you safer online, every day.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20211001-222733/ Fri, 01 Oct 2021 22:27:32 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20211001-222733/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/10/introducing-secure-open-source-pilot.html">Introducing the Secure Open Source Pilot Program</a><br></p> <hr> Posted by Meder Kydyraliev and Kim Lewandowski, Google Open Source Security Team<br> Over the past year we have made a number of investments to strengthen the security of critical open source projects, and recently announced our <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/why-were-committing-10-billion-to-advance-cybersecurity/">$10 billion commitment to cybersecurity defense</a> including $100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities. Today, we are excited to announce our sponsorship for the <a rel="noreferrer" target="_blank" href="https://sos.dev/">Secure Open Source (SOS) pilot program</a> run by the Linux Foundation. This program financially rewards developers for enhancing the security of critical open source projects that we all depend on. We are starting with a $1 million investment and plan to expand the scope of the program based on community feedback.<br> Why SOS?<br> SOS rewards a very broad range of improvements that proactively harden critical open source projects and supporting infrastructure against application and supply chain attacks. To complement existing programs that reward vulnerability management, SOS’s scope is comparatively wider in the type of work it rewards, in order to support project developers.<br> What projects are in scope?<br> Since there is no one definition of what makes an open source project critical, our selection process will be holistic. During submission evaluation we will consider the guidelines established by the <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/2021/06/25/EO%20Critical%20FINAL_1.pdf">National Institute of Standards and Technology’s definition</a> in response to the recent <a rel="noreferrer" target="_blank" href="https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/">Executive Order on Cybersecurity</a> along with criteria listed below:<br> The impact of the project:<br> How many and what types of users will be affected by the security improvements?<br> Will the improvements have a significant impact on infrastructure and user security?<br> If the project were compromised, how serious or wide-reaching would the implications be?<br> The project’s rankings in existing open source criticality research:<br> Is the project included in the <a rel="noreferrer" target="_blank" href="https://www.coreinfrastructure.org/programs/census-program-ii/">Havard 2 Census Study</a> of most-used packages, or does it have a score of 0.6 or above in the <a rel="noreferrer" target="_blank" href="https://github.com/ossf/criticality_score">OpenSSF Critically Score</a> project?<br> What security improvements qualify?<br> The program is initially focused on rewarding the following work:<br> Software supply chain security improvements including hardening CI/CD pipelines and distribution infrastructure. The <a rel="noreferrer" target="_blank" href="http://slsa.dev/">SLSA framework</a> suggests specific requirements to consider, such as basic provenance generation and verification.<br> Adoption of software artifact signing and verification. One option to consider is Sigstore's set of utilities (e.g. <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/cosign">cosign</a> ).<br> Project improvements that produce higher <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard">OpenSSF Scorecard</a> results. For example, a contributor can follow remediation suggestions for the following Scorecard checks:<br> Code-Review<br> Branch-Protection<br> Pinned-Dependencies<br> Dependency-Update-Tool<br> Fuzzing<br> Use of <a rel="noreferrer" target="_blank" href="https://github.com/ossf/allstar">OpenSSF Allstar</a> and remediation of discovered issues.<br> Earning a <a rel="noreferrer" target="_blank" href="https://bestpractices.coreinfrastructure.org/">CII Best Practice Badge</a> (which also improves the Scorecard results).<br> We'll continue adding to the above list, so check our <a rel="noreferrer" target="_blank" href="https://sos.dev/#frequently-asked-questions">FAQ</a> for updates. You may also submit improvements not listed above, if you provide justification and evidence to help us understand the complexity and impact of the work. Only work completed after October 1, 2021 qualifies for SOS rewards. Upfront funding is available on a limited case by case basis for impactful improvements of moderate to high complexity over a longer time span. Such requests should explain why funding is required upfront and provide a detailed plan of how the improvements will be landed.<br> How to participate<br> Review our <a rel="noreferrer" target="_blank" href="https://sos.dev/#frequently-asked-questions">FAQ</a> and fill out <a rel="noreferrer" target="_blank" href="https://docs.google.com/forms/d/e/1FAIpQLSdm8YFKTKHxcYiAyCH8Q9t5mor6jrucYKTp0J9pI60F4zvaqQ/viewform">this form</a> to submit your application. Please include as much data or supporting evidence as possible to help us evaluate the significance of the project and your improvements.<br> Reward amounts<br> Reward amounts are determined based on complexity and impact of work:<br> $10,000 or more for complicated, high-impact and lasting improvements that almost certainly prevent major vulnerabilities in the affected code or supporting infrastructure.<br> $5,000-$10,000 for moderately complex improvements that offer compelling security benefits.<br> $1,000-$5,000 for submissions of modest complexity and impact.<br> $505 for small improvements that nevertheless have merit from a security standpoint.<br> Looking Ahead<br> The SOS program is part of a broader effort to address a growing truth: the world relies on open source software, but widespread support and financial contributions are necessary to keep that software safe and secure. This $1 million investment is just the beginning—we envision the SOS pilot program as the starting point for future efforts that will hopefully bring together other large organizations and turn it into a sustainable, long-term initiative under the OpenSSF. We welcome <a rel="noreferrer" target="_blank" href="mailto:sos-rewards@googlegroups.com">community feedback</a> and interest from others who want to contribute to the SOS program. Together we can pool our support to give back to the open source community that makes the modern internet possible.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210928-161539/ Tue, 28 Sep 2021 16:15:38 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210928-161539/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/09/announcing-new-patch-reward-program-for.html">Announcing New Patch Reward Program for Tsunami Security Scanner</a><br></p> <hr> Posted by Guoli Ma, Sebastian Lekies & Claudio Criscione, Google Vulnerability Management Team One year ago, we <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2020/06/tsunami-extensible-network-scanning.html">published</a> the <a rel="noreferrer" target="_blank" href="https://github.com/google/tsunami-security-scanner">Tsunami security scanner</a> with the goal of detecting high severity, actively exploited vulnerabilities with high confidence. In the last several months, the Tsunami scanner team has been working closely with our vulnerability rewards program, <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about">Bug Hunters</a> , to further improve Tsunami's security detection capabilities. Today, we are announcing a new experimental Patch Reward Program for the Tsunami project. Participants in the program will receive patch rewards for providing novel Tsunami detection plugins and web application fingerprints. We hope this program will allow us to quickly extend the detection capabilities of the scanner to better benefit our users and uncover more vulnerabilities in their network infrastructure. For this launch, we will accept two types of contributions:<br> Vulnerability detection plugins: In order to expand Tsunami scanner's detection capabilities, we encourage everyone who is interested in making contributions to this project to add new vulnerabilities detection plugins. All plugin contributions will be reviewed by our panel members in Google's Vulnerability Management team and the reward amount will be determined by the severity as well as the time sensitivity of the vulnerability.<br> Web application fingerprints: Several months ago, we added new web application fingerprinting capabilities to Tsunami that detect popular off-the-shelf web applications. It achieves this goal by matching application fingerprints against a database of known web application fingerprints. More fingerprint data is needed for this approach to support more web applications. You will be rewarded with a flat amount for each application added to the database.<br> As with other Security Reward Programs, rewards can be donated to charity—and we'll double your donation if you choose to do so. We'll run this program in iterations so that everyone interested has the opportunity to participate. To learn more about this program, please check out our <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/about/rules/4928084514701312">official rules and guidelines</a> . And if you have any questions or suggestions for the program, feel free to contact us at <a rel="noreferrer" target="_blank" href="mailto:tsunami-patch-rewards@google.com">tsunami-patch-rewards@google.com</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210928-081355/ Tue, 28 Sep 2021 08:13:55 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210928-081355/ September 22, 2021<br> $ cosign verify-attestation -key cosign.pub gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91<br> Verification for gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91 –<br> $ rekor-cli search –sha sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91<br> af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8<br> $ rekor-cli get –uuid af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8 –format json | jq -r .Attestation | base64 –decode | jq<br> "sha256": "703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d"<br> "sha256": "d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce"<br> "sha256": "2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661"<br> "sha256": "4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91"<br> "sha256": "dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980"<br> "sha256": "c9507268813f235b11e63a7ae01526b180c94858bd718d6b4746c9c0e8425f7a"<br> "sha256": "4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d"<br> "sha256": "2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb"<br> "sha256": "deb41661be772c6256194eb1df6b526cc95a6f60e5f5b740dda2769b20778c51"<br> "sha256": "927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf"<br> "sha256": "f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58"<br> "sha256": "aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878"<br> "sha256": "9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d"<br> "sha256": "e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2"<br> "CHAINS-GIT_COMMIT={string 976c1c9bc178ac0371d8888d69893145c3df09f0 []}",<br> "event_id": "531c282f-806e-41e4-b3ad-b596c4283381",<br> "image": "docker.io/library/golang@sha256:cb1a7482cb5cfc52527c5cdea5159419292360087d5249e3fe5472f3477be642"<br> "buildStartedOn": "2021-09-16T00:03:04Z",<br> "buildFinishedOn": "2021-09-16T00:04:36Z"<br> "revision": "976c1c9bc178ac0371d8888d69893145c3df09f0"<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210922-161817/ Wed, 22 Sep 2021 16:18:16 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210922-161817/ <p>Posted by Priya Wadhwa and Appu Goundan, Google Open Source Security Team<br> A few months ago we announced that we started <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/making-internet-more-secure-one-signed.html">signing all distroless images with cosign</a> , which allows users to verify that they have the correct image before starting the build process. Signing our images was our first step towards fully securing the distroless supply chain. Since then, we’ve implemented even more accountability in our supply chain and are excited to announce that distroless builds have achieved <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/levels.md#level-requirements">SLSA 2</a> . SLSA is a <a rel="noreferrer" target="_blank" href="https://slsa.dev/">security framework</a> for increasing supply chain security, and Level 2 ensures that the build service is tamper resistant. This means that in addition to a signature, each distroless image now has an associated signed provenance. This provenance is an in-toto attestation and includes information around how each image was built, what command was run, and what build system was used. It also includes any special parameters that were passed in, the exact commit the images were built at, and more. This provenance is a useful tool for builds that need to be audited in the future.<br> SLSA 2 Requirement<br> Distroless<br> Source - <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/requirements.md#version-controlled">Version controlled</a><br> Source code in Github<br> Build - <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/requirements.md#scripted-build">Scripted build</a><br> Build script exists as a Tekton Pipeline, invoked as a Google Cloud Build step<br> Build - <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/requirements.md#build-service">Build service</a><br> All steps run on Kubernetes with Tekton<br> Provenance - <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/requirements.md#available">Available</a><br> Provenance is available in the rekor transparency log as an in-toto attestation<br> Provenance - <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/requirements.md#authenticated">Authenticated</a><br> Provenance is signed with the distroless GCP KMS key<br> Provenance - <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/docs/requirements.md#service-generated">Service generated</a><br> Provenance is generated by Tekton Chains from a Tekton TaskRun<br> Achieving SLSA 2 required some changes to the distroless build pipeline: we set up Tekton Pipelines and <a rel="noreferrer" target="_blank" href="https://github.com/tektoncd/chains">Tekton Chains</a> in a GKE cluster to automate building images and generating provenance. Every time a pull request is merged to the distroless Github repo, a Tekton Pipeline is triggered. This Pipeline builds the distroless images, and Tekton Chains is responsible for generating signed provenance for each image. Tekton Chains stores the signed provenance alongside the image in an OCI registry and also stores a record of the provenance in the <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/rekor">rekor</a> transparency log. Don't trust us? You can try the build yourself. Because distroless builds are reproducible, all the information to replicate the build is in the provenance, and you or a trusted third party can build the image yourselves and verify the build is correct by matching image digests. You can verify an attestation for a distroless image with <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/cosign">cosign</a> and the distroless <a rel="noreferrer" target="_blank" href="https://raw.githubusercontent.com/GoogleContainerTools/distroless/main/cosign.pub">public key</a> :<br> $ cosign verify-attestation -key cosign.pub gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91<br> Verification for gcr.io/distroless/base@sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91 –<br> The following checks were performed on each of these signatures:<br></p> <ul> <li>The cosign claims were validated<br></li> <li>The signatures were verified against the specified public key<br></li> <li>Any certificates were verified against the Fulcio roots.<br> …<br> And you can find the provenance for the image in the rekor transparency log with the <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/rekor/releases/">rekor-cli</a> tool. For example, you could find the provenance for the above image by using the image’s digest and running:<br> $ rekor-cli search –sha sha256:4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91<br> af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8<br> $ rekor-cli get –uuid af7a9687d263504ccdb2759169c9903d8760775045c6e7554e365ec2bf29f6f8 –format json | jq -r .Attestation | base64 –decode | jq<br> "_type": "distroless-provenance",<br> "predicateType": "https://tekton.dev/chains/provenance",<br> "subject": [<br> "name": "gcr.io/distroless/base",<br> "digest": {<br> "sha256": "703a4726aedc9ec7a7e32251087565246db117bb9a141a7993d1c4bb4036660d"<br> "sha256": "d322ed16d530596c37eee3eb57a039677502aa71f0e4739b0272b1ebd8be9bce"<br> "sha256": "2dfdd5bf591d0da3f67a25f3fc96d929b256d5be3e0af084db10952e5da2c661"<br> "sha256": "4f8aa0aba190e375a5a53bb71a303c89d9734c817714aeaca9bb23b82135ed91"<br> "sha256": "dc0a793d83196a239abf3ba035b3d1a0c7a24184856c2649666e84bc82fc5980"<br> "name": "gcr.io/distroless/base-debian10",<br> "sha256": "c9507268813f235b11e63a7ae01526b180c94858bd718d6b4746c9c0e8425f7a"<br> "name": "gcr.io/distroless/cc",<br> "sha256": "4af613acf571a1b86b1d3c50682caada0b82024e566c1c4c2fe485a70f3af47d"<br> "sha256": "2c4bb6b7236db0a55ec54ba8845e4031f5db2be957ac61867872bf42e56c4deb"<br> "name": "gcr.io/distroless/cc-debian10",<br> "name": "gcr.io/distroless/java",<br> "sha256": "deb41661be772c6256194eb1df6b526cc95a6f60e5f5b740dda2769b20778c51"<br> "name": "gcr.io/distroless/nodejs",<br> "sha256": "927dd07e7373e1883469c95f4ecb31fe63c3acd104aac1655e15cfa9ae0899bf"<br> "sha256": "f106757268ab4e650b032e78df0372a35914ed346c219359b58b3d863ad9fb58"<br> "name": "gcr.io/distroless/nodejs-debian10",<br> "name": "gcr.io/distroless/python3",<br> "sha256": "aa8a0358b2813e8b48a54c7504316c7dcea59d6ae50daa0228847de852c83878"<br> "name": "gcr.io/distroless/python3-debian10",<br> "name": "gcr.io/distroless/static",<br> "sha256": "9acfd1fdf62b26cbd4f3c31422cf1edf3b7b01a9ecee00a499ef8b7e3536914d"<br> "sha256": "e50641dbb871f78831f9aa7ffa59ec8f44d4cc33ae4ee992c9f4b046040e97f2"<br> "name": "gcr.io/distroless/static-debian10",<br> ],<br> "predicate": {<br> "invocation": {<br> "parameters": [<br> "MANIFEST_SUBSECTION={string 0 []}",<br> "CHAINS-GIT_COMMIT={string 976c1c9bc178ac0371d8888d69893145c3df09f0 []}",<br> "CHAINS-GIT_URL={string https://github.com/GoogleContainerTools/distroless []}"<br> "recipe_uri": "task://distroless-provenance",<br> "event_id": "531c282f-806e-41e4-b3ad-b596c4283381",<br> "builder.id": "tekton-chains"<br> "recipe": {<br> "steps": [<br> "entryPoint": "#!/bin/sh\nset -ex\n\n# get the digests for a subset of images built, and store in the IMAGES result\ngo run provenance/provenance.go images $(params.MANIFEST_SUBSECTION) > $(results.IMAGES.path)\n",<br> "arguments": null,<br> "environment": {<br> "container": "provenance",<br> "image": "docker.io/library/golang@sha256:cb1a7482cb5cfc52527c5cdea5159419292360087d5249e3fe5472f3477be642"<br> "annotations": null<br> ]<br> "metadata": {<br> "buildStartedOn": "2021-09-16T00:03:04Z",<br> "buildFinishedOn": "2021-09-16T00:04:36Z"<br> "materials": [<br> "uri": "https://github.com/GoogleContainerTools/distroless",<br> "revision": "976c1c9bc178ac0371d8888d69893145c3df09f0"<br> As you might guess, our next step is getting distroless to SLSA 3, which will require adding non-falsifiable provenance and isolated builds to the distroless supply chain. Stay tuned for more!<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Open%20Source">Open Source</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/supply%20chain">supply chain</a><br></li> </ul> https://www.whatsupup.com/blog/ewing/undiscernibly/20210921-201627/ Tue, 21 Sep 2021 20:16:26 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210921-201627/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html">An update on Memory Safety in Chrome</a><br></p> <hr> Adrian Taylor, Andrew Whalley, Dana Jansens and Nasko Oskov, Chrome security team<br> Security is a cat-and-mouse game. As attackers innovate, browsers always have to mount new defenses to stay ahead, and Chrome has invested in ever-stronger multi-process architecture built on <a rel="noreferrer" target="_blank" href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/design/sandbox.md">sandboxing</a> and <a rel="noreferrer" target="_blank" href="https://www.chromium.org/Home/chromium-security/site-isolation">site isolation</a> . Combined with <a rel="noreferrer" target="_blank" href="https://chromium.googlesource.com/chromium/src/+/HEAD/testing/libfuzzer/README.md">fuzzing</a> , these are still our primary lines of defense, but they <a rel="noreferrer" target="_blank" href="https://www.usenix.org/conference/enigma2021/presentation/palmer">are reaching their limits</a> , and we can no longer solely rely on this strategy to defeat <a rel="noreferrer" target="_blank" href="https://googleprojectzero.blogspot.com/p/0day.html">in-the-wild attacks</a> .<br> Last year, we showed that <a rel="noreferrer" target="_blank" href="https://www.chromium.org/Home/chromium-security/memory-safety">more than 70% of our severe security bugs are memory safety problems</a> . That is, mistakes with pointers in the C or C++ languages which cause memory to be misinterpreted.<br> This sounds like a problem! And, certainly, memory safety is an issue which needs to be taken seriously by the global software engineering community. Yet it’s also an opportunity because many bugs have the same sorts of root-causes, meaning we may be able to squash a high proportion of our bugs in one step.<br> Chrome has been exploring three broad avenues to seize this opportunity:<br> Make C++ safer through compile-time checks that pointers are correct.<br> Make C++ safer through runtime checks that pointers are correct.<br> Investigating use of a memory safe language for parts of our codebase.<br> “Compile-time checks” mean that safety is guaranteed during the Chrome build process, before Chrome even gets to your device. “Runtime” means we do checks whilst Chrome is running on your device.<br> Runtime checks have a performance cost. Checking the correctness of a pointer is an infinitesimal cost in memory and CPU time. But with millions of pointers, <a rel="noreferrer" target="_blank" href="https://www.youtube.com/watch?v=rHIkrotSwcc">it adds up</a> . And since Chrome performance is important to billions of users, many of whom are using low-power mobile devices without much memory, an increase in these checks would result in a slower web.<br> Ideally we’d choose option 1 - make C++ safer, at compile time. Unfortunately, the language just isn’t designed that way. You can learn more about the investigation we've done in this area in <a rel="noreferrer" target="_blank" href="https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub">Borrowing Trouble: The Difficulties Of A C++ Borrow-Checker</a> that we're also publishing today.<br> So, we’re mostly left with options 2 and 3 - <a rel="noreferrer" target="_blank" href="https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub">make C++ safer</a> (but slower!) or start to use a different language. Chrome Security is experimenting with both of these approaches.<br> You’ll see major investments in C++ safety solutions - such as <a rel="noreferrer" target="_blank" href="https://chromium.googlesource.com/chromium/src/+/ddc017f9569973a731a574be4199d8400616f5a5/base/memory/raw_ptr.md">MiraclePtr</a> and <a rel="noreferrer" target="_blank" href="https://crbug.com/1072380">ABSL/STL hardened modes</a> . In each case, we hope to eliminate a sizable fraction of our exploitable security bugs, but we also expect some performance penalty. For example, MiraclePtr prevents use-after-free bugs by quarantining memory that may still be referenced. On many mobile devices, memory is very precious and it’s hard to spare some for a quarantine. Nevertheless, MiraclePtr stands a chance of eliminating over 50% of the use-after-free bugs in the browser process - an enormous win for Chrome security, right now.<br> In parallel, we’ll be exploring whether we can use a memory safe language for parts of Chrome in the future. The leading contender is <a rel="noreferrer" target="_blank" href="https://www.rust-lang.org/">Rust</a> , invented by our friends at Mozilla. This is (largely) compile-time safe; that is, the Rust compiler spots mistakes with pointers before the code even gets to your device, and thus there’s no performance penalty. Yet there are <a rel="noreferrer" target="_blank" href="https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability">open questions about whether we can make C++ and Rust work well enough together</a> . Even if we started writing new large components in Rust tomorrow, we’d be unlikely to eliminate a significant proportion of security vulnerabilities for many years. And can we make the language boundary clean enough that we can write parts of existing components in Rust? We don’t know yet. We’ve started to land limited, non-user-facing Rust experiments in the <a rel="noreferrer" target="_blank" href="https://source.chromium.org/chromium/chromium/src/+/main:build/config/rust.gni">Chromium source code tree</a> , but we’re not yet using it in production versions of Chrome - we remain in an experimental phase.<br> That’s why we’re pursuing both strategies in parallel. Watch this space for updates on our adventures in making C++ safer, and efforts to experiment with a new language in Chrome.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/C%2B%2B">C++</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/chrome">chrome</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/chrome%20security">chrome security</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210915-201455/ Wed, 15 Sep 2021 20:14:54 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210915-201455/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/09/google-supports-open-source-technology.html">Google Supports Open Source Technology Improvement Fund</a><br></p> <hr> Posted by Kaylin Trychon, Google Open Source Security Team<br> We <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/why-were-committing-10-billion-to-advance-cybersecurity/">recently pledged</a> to provide $100 million to support third-party foundations that manage open source security priorities and help fix vulnerabilities. As part of this commitment, we are excited to <a rel="noreferrer" target="_blank" href="https://ostif.org/google-is-partnering-with-open-source-technology-improvement-fund-inc-to-sponsor-security-reviews-of-critical-open-source-software/">announce</a> our support of the Open Source Technology Improvement Fund (OSTIF) to improve security of eight open-source projects. Google’s support will allow OSTIF to launch the Managed Audit Program (MAP), which will expand in-depth security reviews to critical projects vital to the open source ecosystem. The eight libraries, frameworks and apps that were selected for this round are those that would benefit the most from security improvements and make the largest impact on the open-source ecosystem that relies on them. The projects include:<br> Git - de facto version control software used in modern DevOps.<br> Lodash - a modern JavaScript utility library with over 200 functions to facilitate web development, can be found in most environments that support JavaScript, which is most of the world wide web.<br> Laravel - a php web application framework that is used by many modern, full-stack web applications, including integrations with Google Cloud.<br> Slf4j - a logging facade for various Java logging frameworks.<br> Jackson-core & Jackson-databind - a JSON for Java, Streaming API, and extra shared components and the base for <a rel="noreferrer" target="_blank" href="https://github.com/FasterXML/jackson-databind">Jackson data-bind</a> package.<br> Httpcomponents-core & Httpcomponents-client - these projects are responsible for creating and maintaining a toolset of low-level Java components focused on HTTP and associated protocols.<br> We are excited to help OSTIF build a safer open source environment for everyone. If you are interested in getting involved or learning more <a rel="noreferrer" target="_blank" href="https://ostif.org/google-is-partnering-with-open-source-technology-improvement-fund-inc-to-sponsor-security-reviews-of-critical-open-source-software/">please visit the OSTIF blog</a> .<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Open%20Source">Open Source</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210909-201313/ Thu, 09 Sep 2021 20:13:13 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210909-201313/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/09/introducing-androids-private-compute.html">Introducing Android’s Private Compute Services</a><br></p> <hr> Posted by Suzanne Frey, VP, Product, Android & Play Security and Privacy<br> We introduced <a rel="noreferrer" target="_blank" href="https://blog.google/products/android/android-12-beta/">Android’s Private Compute Core</a> in Android 12 Beta. Today, we're excited to announce a new suite of services that provide a privacy-preserving bridge between Private Compute Core and the cloud.<br> Recap: What is Private Compute Core ?<br> Android’s Private Compute Core is an open source, secure environment that is isolated from the rest of the operating system and apps. With each new Android release we’ll add more privacy-preserving features to the Private Compute Core. Today, these include:<br> <a rel="noreferrer" target="_blank" href="https://blog.google/products/android/live-caption/">Live Caption</a> , which adds captions to any media using Google’s on-device speech recognition<br> Now Playing, which recognizes music playing nearby and displays the song title and artist name on your device’s lock screen<br> Smart Reply, which suggests relevant responses based on the conversation you’re having in messaging apps<br> For these features to be private, they must:<br> Keep the information on your device private. Android ensures that the sensitive data processed in the Private Compute Core is not shared to any apps without you taking an action. For instance, until you tap a Smart Reply, the OS keeps your reply hidden from both your keyboard and the app you’re typing into.<br> Let your device use the cloud (to download new song catalogs or speech-recognition models) without compromising your privacy. This is where Private Compute Services comes in.<br> Introducing Android’s Private Compute Services<br> Machine learning features often improve by updating models, and Private Compute Services helps features get these updates over a private path. Android prevents any feature inside the Private Compute Core from having direct access to the network. Instead, features communicate over a small set of purposeful open-source APIs to Private Compute Services, which strips out identifying information and uses a set of privacy technologies, including <a rel="noreferrer" target="_blank" href="https://ai.googleblog.com/2017/04/federated-learning-collaborative.html">Federated Learning</a> , <a rel="noreferrer" target="_blank" href="https://ai.googleblog.com/2020/05/federated-analytics-collaborative-data.html">Federated Analytics</a> , and <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Private_information_retrieval">Private information retrieval</a> .<br> We will publicly publish the source code for Private Compute Services, so it can be audited by security researchers and other teams outside of Google. This means it can go through the same rigorous security <a rel="noreferrer" target="_blank" href="https://www.google.com/about/appsecurity/android-rewards/">programs</a> that ensure the safety of the Android platform.<br> We’re enthusiastic about the potential for machine learning to power more helpful features inside Android, and Android’s Private Compute Core will help users benefit from these features while strengthening privacy protections via the new Private Compute Services. Android is the first open source mobile OS to include this kind of externally verifiable privacy; Private Compute Services helps the Android OS continue to innovate in machine learning, while also maintaining the highest standards of privacy and security.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android">android</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android%20security">android security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/private%20compute%20core">private compute core</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210826-201424/ Thu, 26 Aug 2021 20:14:23 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210826-201424/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/updates-on-our-continued-collaboration.html">Updates on our continued collaboration with NIST to secure the Software Supply Chain</a><br></p> <hr> Posted by Eric Brewer and Dan Lorenc Yesterday, we were honored to participate in President Biden’s White House Cyber Security Summit where we <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/why-were-committing-10-billion-to-advance-cybersecurity/">shared</a> recommendations to advance the administration’s cybersecurity agenda. This included our commitment to invest $10 billion over the next five years to expand zero-trust programs, help secure the software supply chain, and enhance open-source security. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/updates-on-our-continued-collaboration.html">Read More</a><br> Posted by Eric Brewer and Dan Lorenc<br> Yesterday, we were honored to participate in President Biden’s White House Cyber Security Summit where we <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/why-were-committing-10-billion-to-advance-cybersecurity/">shared</a> recommendations to advance the administration’s cybersecurity agenda. This included our commitment to invest $10 billion over the next five years to expand zero-trust programs, help secure the software supply chain, and enhance open-source security. At Google, we’ve long advocated for securing the <a rel="noreferrer" target="_blank" href="https://cloud.google.com/blog/products/identity-security/how-were-helping-reshape-software-supply-chain-ecosystem-securely">software supply chain</a> both through our <a rel="noreferrer" target="_blank" href="https://cloud.google.com/blog/products/identity-security/applying-zero-trust-to-user-access-and-production-services">internal best practices</a> and industry efforts that enhance the integrity and security of software. That’s why we're thrilled to collaborate with the U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) to support and develop a new <a rel="noreferrer" target="_blank" href="https://www.whitehouse.gov/briefing-room/statements-releases/2021/08/25/fact-sheet-biden-administration-and-private-sector-leaders-announce-ambitious-initiatives-to-bolster-the-nations-cybersecurity/">framework</a> that will help to improve the security and integrity of the technology supply chain. This builds on our previous work in June of this year, where we submitted four statements in response to the National Telecommunications and Information Administration (NTIA) and NIST’s <a rel="noreferrer" target="_blank" href="https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/workshop-and-call-position-papers">call for position papers</a> to help guide adoption of new software supply chain security standards and guidelines that fulfill components of the <a rel="noreferrer" target="_blank" href="https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/">Executive Order on Improving the Nation’s Cybersecurity</a> . The papers lay out concrete ways to increase the nation’s cybersecurity, based on Google’s experience building secure by design systems for our users and enterprise customers. Each of the suggestions are enactable solutions for software supply chain security, and were drawn from Google’s research and innovations in engineering away entire classes of vulnerabilities. NIST and NTIA also released their guidelines in July for several of the Executive Order’s target areas ( <a rel="noreferrer" target="_blank" href="https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf">SBOM Minimum Elements</a> , <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/2021/07/09/Critical%20Software%20Use%20Security%20Measures%20Guidance.pdf">Critical Software Guidelines</a> , <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/2021/07/13/Developer%20Verification%20of%20Software.pdf">Developer Verification of Software</a> ), incorporating specific recommendations from Google. Below are summaries of each of Google’s position papers, and background on our contributions and impact in each area.<br> <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/noindex/2021/06/08/Google%20NIST%20statement%20on%20%282%29%20development.pdf">High-Confidence, Scalable Secure Development</a> Instead of being reactive to vulnerabilities, we should eliminate them proactively with secure languages, platforms, and frameworks that stop entire classes of bugs. Preventing problems before they leave the developer’s keyboard is safer and more cost effective than trying to fix vulnerabilities and their fallout. (Consider the enormous impact of the SolarWinds attack, which is predicted to take <a rel="noreferrer" target="_blank" href="https://www.rpc.senate.gov/policy-papers/the-solarwinds-cyberattack">$100 billion to remediate</a> .) Google promotes designs that are secure by default and impervious to simple errors that can lead to security vulnerabilities. We want to see secure systems used as widely as possible, so we have invested in initiatives such as getting <a rel="noreferrer" target="_blank" href="https://www.linuxfoundation.org/en/press-release/google-funds-linux-kernel-developers-to-focus-exclusively-on-security/">Rust into the Linux Kernel</a> , published <a rel="noreferrer" target="_blank" href="https://research.google/pubs/pub42934/">research papers</a> , and shared <a rel="noreferrer" target="_blank" href="https://queue.acm.org/detail.cfm?id=3447806&doi=10.1145%2F3442632.3447806">guidance on secure frameworks</a> .<br> <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/noindex/2021/06/08/Google%20NIST%20statement%20on%20%283%29%20security%20measures.pdf">Security Measures for Critical Software</a> Critical software does not exist in a vacuum; we must also harden the broader systems and run environments. Our paper outlines a list of actionable steps for critical software's configuration, the privileges with which it runs, and the network(s) to which it is connected. Our suggestions are based on practices that have withstood the tests of time and scale, such as in our Google Cloud Products, built on <a rel="noreferrer" target="_blank" href="https://cloud.google.com/blog/products/identity-security/delivering-the-industrys-most-trusted-cloud">one of the industry’s most trusted clouds</a> . Google contributes to open-source tools that help maintainers adopt these practices, such as <a rel="noreferrer" target="_blank" href="https://cloud.google.com/blog/products/containers-kubernetes/how-gvisor-protects-google-cloud-services-from-cve-2020-14386">gVisor</a> for sandboxing, and <a rel="noreferrer" target="_blank" href="https://github.com/google/glome">GLOME</a> for authentication and authorization. Additionally, to share the knowledge we have gained securing systems that serve billions of users, we released our book <a rel="noreferrer" target="_blank" href="https://sre.google/books/building-secure-reliable-systems/">Building Secure and Reliable Systems</a> , a resource for any organization that wants to design systems that are fundamentally secure, reliable, and scalable.<br> <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/noindex/2021/06/08/Google%20NIST%20statement%20on%20%284%29%20testing.pdf">Software Source Code Testing</a> <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2019/02/open-sourcing-clusterfuzz.html">Continuous fuzzing</a> is indispensable for identifying bugs and catching vulnerabilities before attackers do. We also suggest securing dependencies using automated tools such as <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard">Scorecards</a> , <a rel="noreferrer" target="_blank" href="https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/">Dependabot</a> , and <a rel="noreferrer" target="_blank" href="https://osv.dev/">OSV</a> . Google has made huge contributions to the field of fuzzing, and has found tens of thousands of bugs with tools like <a rel="noreferrer" target="_blank" href="https://llvm.org/docs/LibFuzzer.html">libFuzzer</a> and <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2019/02/open-sourcing-clusterfuzz.html">ClusterFuzz</a> . We have made continuous fuzzing available to all developers through <a rel="noreferrer" target="_blank" href="https://google.github.io/oss-fuzz/getting-started/continuous-integration/">OSS-Fuzz</a> , and are <a rel="noreferrer" target="_blank" href="https://google.github.io/oss-fuzz/getting-started/integration-rewards/">funding integration costs</a> and <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/10/fuzzing-internships-for-open-source.html">fuzzing internships</a> . We are leading a shift in industry support: on top of <a rel="noreferrer" target="_blank" href="https://www.google.com/about/appsecurity/reward-program/index.html">bug bounties</a> , which are rewards programs for finding bugs, we have also added <a rel="noreferrer" target="_blank" href="https://www.google.com/about/appsecurity/patch-rewards/">patch rewards</a> , money that can help fund maintainers remediate uncovered bugs.<br> <a rel="noreferrer" target="_blank" href="https://www.nist.gov/system/files/documents/noindex/2021/06/08/Google%20NIST%20statement%20on%20%285%29%20integrity.pdf">Software Supply Chain Integrity</a> Google strongly encourages adoption of <a rel="noreferrer" target="_blank" href="http://slsa.dev/">SLSA</a> , an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. Four “SLSA Levels” provide incrementally adoptable guidelines that each raise the bar on security standards for open-source software. SLSA is based on Google’s <a rel="noreferrer" target="_blank" href="https://cloud.google.com/security/binary-authorization-for-borg">internal framework</a> Binary Authorization for Borg (BAB) that ensures that all software packages used by the company meet high integrity standards. Given BAB’s success, we have adapted the framework to work for systems beyond Google and released it as SLSA to help protect other organizations and platforms. We have shared many of Google’s practices for security and reliability in our <a rel="noreferrer" target="_blank" href="https://sre.google/books/">Site Reliability Engineering</a> book. Following our recent <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html">introduction of SLSA</a> to the wider public, we are looking forward to making improvements in response to community feedback.<br> <a rel="noreferrer" target="_blank" href="https://www.ntia.doc.gov/files/ntia/publications/google_-_2021.06.17.pdf">Minimum Requirements for SBOMs</a> Google submitted an additional paper in response to the NTIA’s <a rel="noreferrer" target="_blank" href="https://www.ntia.gov/federal-register-notice/2021/notice-rfc-software-bill-materials-elements-considerations">request for comments</a> on creating SBOMs, which will give users information about a software package’s contents. Modern development requires different approaches than classic packaged software, which means SBOMs must also deal with intermediate artifacts like containers and library dependencies. SBOMs need a reasonable signal-to-noise ratio: if they contain too much information, they won’t be useful, so we urge the NTIA to establish both minimum and maximum requirements on granularity and depth for specific use-cases. We also recommend considerations for the creation of trustworthy SBOMs, such as using verifiable data generation methods to capture metadata, and preparing for the automation and tooling technologies that will be key for widespread SBOM adoption.<br> Improving Everyone’s Security We are committed to <a rel="noreferrer" target="_blank" href="https://blog.google/technology/safety-security/how-google-supports-todays-critical-cybersecurity-efforts/">helping advance collective cybersecurity</a> . We also realize that too many guidelines and lists of best practices can become overwhelming, but any incremental changes in the right direction make a real difference. We encourage companies and maintainers to start evaluating today where they stand on the most important security postures, and to make improvements with the guidance of these papers in the areas of greatest risk. No single entity can fix the problems we all face in this area, but by being open about our practices and sharing our research and tools, we can all help raise the standards for our collective security.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/%23supplychain%20%23security%20%23opensource">#supplychain #security #opensource</a><br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/%23supplychain%20%23security%20%23opensource">#supplychain #security #opensource</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210812-001822/ Thu, 12 Aug 2021 00:18:21 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210812-001822/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/allstar-continuous-security-policy.html">AllStar: Continuous Security Policy Enforcement for GitHub Projects</a><br></p> <hr> Posted by Mike Maraya, Google Open Source Security Team<br> As an active member of the open source software (OSS) community, Google recognizes the growing threat of software supply chain <a rel="noreferrer" target="_blank" href="https://www.sonatype.com/hubfs/Corporate/Software%20Supply%20Chain/2020/SON_SSSC-Report-2020_final_aug11.pdf#page=7">attacks</a> against OSS we use and develop. Building on our efforts to improve OSS security with an end-to-end framework ( <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html">SLSA</a> ), metrics ( <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/measuring-security-risks-in-open-source.html">Scorecards</a> ), and coordinated vulnerability disclosure ( <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-vulnerability-guide">guide</a> ), we are excited to announce <a rel="noreferrer" target="_blank" href="https://github.com/ossf/allstar">Allstar</a> .<br> Allstar is a GitHub app that continuously enforces security policy settings through selectable automated enforcement actions. Allstar is already filing and closing security <a rel="noreferrer" target="_blank" href="https://github.com/search?q=%22Issue+created+by+Allstar.+https%3A%2F%2Fgithub.com%2Fossf%2Fallstar%22&type=issues">issues</a> for <a rel="noreferrer" target="_blank" href="https://www.envoyproxy.io/">Envoy</a> and <a rel="noreferrer" target="_blank" href="https://github.com/GoogleContainerTools">GoogleContainerTools</a> , with more organizations and repositories lined up.<br> See the <a rel="noreferrer" target="_blank" href="https://openssf.org/blog/2021/08/11/introducing-the-allstar-github-app/">OpenSSF announcement</a> for more information on Allstar.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210810-082205/ Tue, 10 Aug 2021 08:22:04 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210810-082205/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/simplifying-titan-security-key-options.html">Simplifying Titan Security Key options for our users</a><br></p> <hr> Posted by Christiaan Brand, Product Manager, Google Cloud<br> Today we are excited to announce some changes to our lineup of <a rel="noreferrer" target="_blank" href="https://store.google.com/us/product/titan_security_key">Titan Security Keys on the Google Store</a> which provide a simpler experience and make choosing the right security key for you even easier. We will now offer only two types of Titan Security Keys: a USB-A and a USB-C version. Both of these keys have Near Field Communication (NFC) functionality, which allows you to use it with most mobile devices by simply tapping it on the back of your mobile device in order to sign in securely. These keys will be available for all users starting tomorrow, August 10. In 2018, <a rel="noreferrer" target="_blank" href="https://cloud.google.com/blog/products/identity-security/titan-security-keys-now-available-on-the-google-store">Google introduced the Titan Security Key</a> as a direct defense against credential phishing. Phishing occurs when an attacker tries to trick you into giving them your username and password, and it remains one of the easiest and most successful ways of breaching accounts online. Paired with our <a rel="noreferrer" target="_blank" href="https://landing.google.com/advancedprotection/">Advanced Protection Program</a> and its industry-leading automatic protections, the Titan Security Key remains one of the best ways to keep your Google Account safe.<br> Introducing new Titan Security Key options<br> Since NFC functionality is now supported by a wide range of Android phones and iPhones, we are discontinuing the Bluetooth Titan Security Key and focusing on the easier and more widely available NFC capability. However, for existing users with our Bluetooth Titan Security Keys, these will continue to work with Bluetooth and will continue to work as an NFC key on most modern mobile devices. Applicable warranties for existing Bluetooth Titan Security Keys will continue to be honored per their terms. All Titan Security Keys are built with a hardware secure element chip that includes firmware engineered by Google to verify the key’s integrity. If you have a computer with USB-A ports, we recommend you get the USB-A + NFC security key:<br> If you have a computer with USB-C ports, we recommend you get the USB-C + NFC security key:<br> If you have an iPad with a USB-C connector you can use the USB-C Titan Security Key. If you have an iPad with a lightning connector, it’s recommended to get a USB-A Titan Security Key with an <a rel="noreferrer" target="_blank" href="https://www.apple.com/shop/product/MD821AM/A/lightning-to-usb-camera-adapter">Apple Lightning adapter</a> :<br> To purchase a Titan Security Key, visit the <a rel="noreferrer" target="_blank" href="https://store.google.com/us/product/titan_security_key">Google Store</a> . The USB-A+NFC key,which includes a USB-A to USB-C adapter, is available for $30 and the USB-C+NFC key retails for $35.<br> To learn more about how security keys can help protect you against phishing, visit the <a rel="noreferrer" target="_blank" href="https://cloud.google.com/titan-security-key">Titan Security Key product page</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210805-041958/ Thu, 05 Aug 2021 04:19:57 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210805-041958/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html">Linux Kernel Security Done Right</a><br></p> <hr> Posted by Kees Cook, Software Engineer, Google Open Source Security Team To borrow from an <a rel="noreferrer" target="_blank" href="http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf">excellent analogy</a> between the modern computer ecosystem and the US automotive industry of the 1960s, the Linux kernel runs well: when driving down the highway, you're not sprayed in the face with oil and gasoline, and you quickly get where you want to go. However, in the face of failure, the car may end up on fire, flying off a cliff. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html">Read More</a><br> Posted by Kees Cook, Software Engineer, Google Open Source Security Team To borrow from an <a rel="noreferrer" target="_blank" href="http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf">excellent analogy</a> between the modern computer ecosystem and the US automotive industry of the 1960s, the Linux kernel runs well: when driving down the highway, you're not sprayed in the face with oil and gasoline, and you quickly get where you want to go. However, in the face of failure, the car may end up on fire, flying off a cliff.<br> As we approach its 30th Anniversary, Linux still remains the largest collaborative development project in the history of computing. The huge community surrounding Linux allows it to do amazing things and run smoothly. What's still missing, though, is sufficient focus to make sure that Linux <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Fail-safe">fails well</a> too. There's a strong link between code robustness and security: making it harder for any bugs to manifest makes it harder for security flaws to manifest. But that's not the end of the story. When flaws do manifest, it's important to handle them effectively.<br> Rather than only taking a one-bug-at-a-time perspective, preemptive actions can stop bugs from having bad effects. With Linux written in <a rel="noreferrer" target="_blank" href="https://outflux.net/slides/2019/lca/danger.pdf">C</a> , it will continue to have a long tail of associated <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/01/data-driven-security-hardening-in.html">problems</a> . Linux must be designed to take proactive steps to defend itself from its own risks. Cars have seat belts not because we want to crash, but because it is guaranteed to happen sometimes. Even though everyone wants a safe kernel running on their computer, phone, car, or <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/github/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#list-of-qualifying-repositories-for-mars-2020-helicopter-contributor-badge">interplanetary helicopter</a> , not everyone is in a position to do something about it. Upstream kernel developers can fix bugs, but have no control over what a downstream vendor chooses to incorporate into their products. End users get to choose their products, but don't usually have control over what bugs are fixed nor what kernel is used (a <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Electronics_right_to_repair">problem</a> in itself). Ultimately, vendors are responsible for keeping their product's kernels safe.<br> What to fix?<br> The statistics of tracking and fixing distinct bugs are sobering. The <a rel="noreferrer" target="_blank" href="http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/">stable kernel releases</a> ("bug fixes only") each contain close to 100 new fixes per week. Faced with this high rate of change, a vendor can choose to ignore all the fixes, pick out only "important" fixes, or face the daunting task of taking everything.<br> Fix nothing?<br> With the preponderance of malware, botnets, and state surveillance <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2017/04/an-investigation-of-chrysaor-malware-on.html">targeting flawed software</a> , it's clear that ignoring all fixes is the wrong "solution." Unfortunately this is the very common stance of vendors who see their devices as just a physical product instead of a hybrid product/service that must be regularly <a rel="noreferrer" target="_blank" href="https://datatracker.ietf.org/doc/rfc8996/">updated</a> .<br> Fix important flaws?<br> Between the dereliction of doing nothing and the assumed burden of fixing everything, the traditional vendor choice has been to cherry-pick only the "important" fixes. But what constitutes "important" or even relevant? Just determining whether to implement a fix takes developer time. The prevailing wisdom has been to choose vulnerabilities to fix based on the Mitre <a rel="noreferrer" target="_blank" href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux+kernel%22">CVE</a> list, presuming all important flaws (and therefore fixes) would have an associated CVE. However, given the volume of flaws and their applicability to a particular system, not all security flaws have CVEs assigned, nor are they assigned in a timely manner. Evidence shows that for Linux CVEs, more than 40% had been fixed before the CVE was even assigned, with the average delay being <a rel="noreferrer" target="_blank" href="https://github.com/gregkh/presentation-cve-is-dead">over three months after the fix</a> . Some fixes <a rel="noreferrer" target="_blank" href="https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html">went years</a> without having their security impact recognized. On top of this, product-relevant bugs may not even <a rel="noreferrer" target="_blank" href="https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules">classify</a> for a CVE. Finally, upstream developers aren't actually interested in <a rel="noreferrer" target="_blank" href="https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html#cve-assignment">CVE assignment</a> ; they spend their limited time actually fixing bugs. A vendor relying on cherry-picking is all but guaranteed to miss important vulnerabilities that others are actively fixing, which is almost worse than doing nothing since it creates the illusion that security updates are being appropriately handled.<br> Fix everything!<br> So what is a vendor to do? The answer is simple, if painful: continuously update to the <a rel="noreferrer" target="_blank" href="https://www.kernel.org/">latest kernel release</a> , either major or stable. Tracking major releases means gaining <a rel="noreferrer" target="_blank" href="https://outflux.net/blog/?s=%22security+things%22">security improvements</a> along with bug fixes, while stable releases are bug fixes only. For example, although modern Android phones ship with kernels that are based on major releases from almost <a rel="noreferrer" target="_blank" href="https://source.android.com/devices/architecture/kernel/android-common#compatibility-matrix">two to four years earlier</a> , Android vendors do now, thankfully, <a rel="noreferrer" target="_blank" href="https://source.android.com/devices/architecture/kernel/releases">track stable kernel releases</a> . So even though the features being added to newer major kernels will be missing, all the latest stable kernel fixes are present. Performing continuous kernel updates (major or stable) understandably faces enormous resistance within an organization due to fear of regressions—will the update break the product? The answer is usually that a vendor doesn't know, or that the update frequency is shorter than their time needed for testing. But the problem with updating is not that the kernel might cause regressions; it's that vendors don't have sufficient test coverage and automation to know the answer. Testing must take priority over individual fixes.<br> Make it happen<br> One question remains: how to possibly support all the work continuous updates require? As it turns out, it’s a simple resource allocation problem, and is more easily accomplished than might be imagined: downstream redundancy can be moved into greater upstream collaboration.<br> More engineers for fixing bugs earlier<br> With vendors using old kernels and backporting existing fixes, their engineering resources are doing redundant work. For example, instead of 10 companies each assigning one engineer to backport the same fix independently, those developer hours could be shifted to upstream work where 10 separate bugs could be fixed for everyone in the Linux ecosystem. This would help address the growing backlog of bugs. Looking at just one source of potential kernel security flaws, the <a rel="noreferrer" target="_blank" href="https://syzkaller.appspot.com/upstream">syzkaller dashboard</a> shows the number of open bugs is currently approaching 900 and growing by about <a rel="noreferrer" target="_blank" href="http://web.archive.org/web/20200812135009/https://syzkaller.appspot.com/upstream">100 a year</a> , even with about <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Reported-by%3A+syzbot%2B">400 a year</a> being fixed.<br> More engineers for code review<br> Beyond just squashing bugs after the fact, more focus on upstream code review will help stem the tide of their introduction in the first place, with benefits extending beyond just the immediate bugs caught. Capable code <a rel="noreferrer" target="_blank" href="https://lwn.net/Articles/718411/">review bandwidth</a> is a limited resource. Without enough <a rel="noreferrer" target="_blank" href="https://kernel-recipes.org/en/2016/talks/maintainers-dont-scale/">people dedicated</a> to upstream code review and subsystem maintenance tasks, the entire kernel development process bottlenecks. Long-term Linux robustness depends on developers, but especially on effective kernel <a rel="noreferrer" target="_blank" href="https://www.linuxfoundation.org/blog/role-of-a-linux-kernel-maintainer/">maintainers</a> . Although there is effort in the industry to <a rel="noreferrer" target="_blank" href="https://training.linuxfoundation.org/linux-kernel-development/">train</a> new developers, this has been traditionally justified only by the "feature driven" jobs they can get. But focusing only on product timelines ultimately leads Linux into the <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Tragedy_of_the_commons">Tragedy of the Commons</a> . Expanding the number of maintainers can <a rel="noreferrer" target="_blank" href="https://techdebtpolicy.com/tragedy-of-the-commons/">avoid it</a> . Luckily the "pipeline" for new maintainers is straightforward. Maintainers are built not only from their depth of knowledge of a subsystem's technology, but also from their experience with mentorship of other developers and code review. Training new reviewers must become the norm, motivated by making upstream review part of the job. Today's reviewers become tomorrow's maintainers. If each major kernel subsystem gained four more dedicated maintainers, we could <a rel="noreferrer" target="_blank" href="https://par.nsf.gov/servlets/purl/10106647">double productivity</a> .<br> More engineers for testing and infrastructure<br> Along with more reviewers, improving Linux's <a rel="noreferrer" target="_blank" href="https://www.kernel.org/doc/html/latest/process/development-process.html">development workflow</a> is critical to expanding everyone's ability to contribute. Linux's "email only" workflow is <a rel="noreferrer" target="_blank" href="https://lwn.net/Articles/803619/">showing its age</a> , but the upstream development of more automated <a rel="noreferrer" target="_blank" href="https://patchwork.kernel.org/project/netdevbpf/list/">patch tracking</a> , <a rel="noreferrer" target="_blank" href="https://linux.kernelci.org/job/">continuous integration</a> , <a rel="noreferrer" target="_blank" href="https://github.com/google/syzkaller/issues?q=is%3Aissue+is%3Aopen+label%3A%22syzbot+user+request%22">fuzzing</a> , <a rel="noreferrer" target="_blank" href="https://github.com/google/syzkaller/issues/533">coverage</a> , and <a rel="noreferrer" target="_blank" href="https://www.kernel.org/doc/html/latest/dev-tools/">testing</a> will make the development process significantly more efficient. Additionally, instead of testing kernels after they're released, it's more effective to test during development. When tests are performed against unreleased kernel versions (e.g. <a rel="noreferrer" target="_blank" href="https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git">linux-next</a> ) and <a rel="noreferrer" target="_blank" href="https://groups.io/g/kernelci/message/1142">reported upstream</a> , developers get immediate feedback about bugs. Fixes can be developed before a flaw is ever actually released; it's always easier to <a rel="noreferrer" target="_blank" href="https://www.ministryoftesting.com/dojo/lessons/ten-reasons-why-you-fix-bugs-as-soon-as-you-find-them">fix a bug earlier than later</a> . This " <a rel="noreferrer" target="_blank" href="https://www.ibrahimatlinux.com/uploads/6/3/9/7/6397792/03.pdf">upstream first</a> " approach to product kernel development and testing is extremely efficient. Google has been successfully doing this with <a rel="noreferrer" target="_blank" href="https://lwn.net/Articles/798147/">Chrome OS</a> and <a rel="noreferrer" target="_blank" href="https://lwn.net/Articles/771974/">Android</a> for a while now, and is hardly alone in the industry. It means feature development happens against the latest kernel, and devices are similarly tested as close as possible to the latest upstream kernels, all avoiding duplicated "in-house" effort.<br> More engineers for security and toolchain development<br> Besides dealing reactively to individual bugs and existing maintenance needs, there is also the need to proactively eliminate entire classes of flaws, so developers cannot introduce these types of bugs ever again. Why fix the same kind of security vulnerability 10 times a year when we can stop it from ever appearing again? Over the last few years, various fragile language features and kernel APIs have been eliminated or replaced (e.g. <a rel="noreferrer" target="_blank" href="https://git.kernel.org/linus/0bb95f80a38f82884693194ea720e9cca5e12ada">VLAs</a> , <a rel="noreferrer" target="_blank" href="https://git.kernel.org/linus/a035d552a93bb9ef6048733bb9f2a0dc857ff869">switch fallthrough</a> , <a rel="noreferrer" target="_blank" href="https://git.kernel.org/linus/3d2403fd10a1dbb359b154af41ffed9f2a7520e8">addr_limit</a> ). However, there is still plenty <a rel="noreferrer" target="_blank" href="https://github.com/KSPP/linux/issues">more work to be done</a> . One of the most time-consuming aspects has been the refactoring involved in making these usually invasive and context-sensitive changes across Linux's 25 million lines of code. Beyond kernel code itself, the compiler and toolchain also need to grow more … https://www.whatsupup.com/blog/ewing/undiscernibly/20210727-161627/ Tue, 27 Jul 2021 16:16:27 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210727-161627/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/a-new-chapter-for-googles-vulnerability.html">A new chapter for Google’s Vulnerability Reward Program</a><br></p> <hr> Posted by Jan Keller, Technical Program Manager, Google VRP<br> A little over <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2010/11/rewarding-web-application-security.html">10 years ago</a> , we launched our <a rel="noreferrer" target="_blank" href="https://www.google.com/about/appsecurity/reward-program/">Vulnerability Rewards Program</a> (VRP). Our goal was to establish a channel for security researchers to report bugs to Google and offer an efficient way for us to thank them for helping make Google, our users, and the Internet a safer place. To recap our progress on these goals, here is a snapshot of what VRP has accomplished with the community over the past 10 years:<br> Total bugs rewarded: 11,055<br> Number of rewarded researchers : 2,022<br> Representing 84 different countries<br> Total rewards: $29,357,516<br> To celebrate our anniversary and ensure the next 10 years are just as (or even more) successful and collaborative, we are excited to announce the launch of our new platform, <a rel="noreferrer" target="_blank" href="https://bughunters.google.com/">bughunters.google.com</a> . This new site brings all of our VRPs (Google, Android, Abuse, Chrome and Play) closer together and provides a single intake form that makes it easier for bug hunters to submit issues. Other improvements you will notice include:<br> More opportunities for interaction and a bit of healthy competition through gamification, per-country leaderboards, awards/badges for certain bugs and more!<br> A more functional and aesthetically pleasing leaderboard. We know a lot of you are using your achievements in the VRP to find jobs ( <a rel="noreferrer" target="_blank" href="https://careers.google.com/?src=Online%2FHouse%20Ads%2FBKWS%27">we’re hiring!</a> ) and we hope this acts as a useful resource.<br> A stronger emphasis on learning: Bug hunters can improve their skills through the content available in our new <a rel="noreferrer" target="_blank" href="http://goo.gle/bhu">Bug Hunter University</a><br> Streamlined publication process: we know the value that knowledge sharing brings to our community. That’s why we want to make it easier for you to publish your bug reports.<br> Swag will now be supported for special occasions (we heard you loud and clear!)<br> We also want to take a moment to shine a light on some aspects of the VRP that are not yet well-known, such as:<br> <a rel="noreferrer" target="_blank" href="http://goo.gle/patchz">Submitting patches</a> to open-source software is eligible for a reward<br> We have <a rel="noreferrer" target="_blank" href="http://goo.gle/paperz">rewards for research papers</a> on the security of open source<br> Your open-source software <a rel="noreferrer" target="_blank" href="http://goo.gle/subsidiz">might be eligible for a subsidy</a><br> When we launched our very first VRP, we had no idea how many valid vulnerabilities - if any - would be submitted on the first day. Everyone on the team put in their estimate, with predictions ranging from zero to 20. In the end, we actually received more than 25 reports, taking all of us by surprise. Since its inception, the VRP program has not only grown significantly in terms of report volume, but the team of security engineers behind it has also expanded – including almost 20 bug hunters who reported vulnerabilities to us and ended up joining the Google VRP team. That is why we are thrilled to bring you this new platform, continue to grow our community of bug hunters and support the skill development of up-and-coming vulnerability researchers. Thanks again to the entire Google bug hunter community for making our vulnerability rewards program successful. As you continue to play around with the new site and reporting system, tell us about it - we would love to <a rel="noreferrer" target="_blank" href="http://twitter.com/googlevrp">hear your feedback</a> . Until next time, keep on finding those bugs!<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/vulnerabilities">vulnerabilities</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210720-201633/ Tue, 20 Jul 2021 20:16:32 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210720-201633/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/protecting-more-with-site-isolation.html">Protecting more with Site Isolation</a><br></p> <hr> Posted by Charlie Reis​ and Alex Moshchuk, Chrome Security Team<br> Chrome's Site Isolation is an essential security defense that makes it harder for malicious web sites to steal data from other web sites. On Windows, Mac, Linux, and Chrome OS, Site Isolation <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html">protects all web sites</a> from each other, and also ensures they <a rel="noreferrer" target="_blank" href="https://blog.chromium.org/2017/05/improving-extension-security-with-out.html">do not share processes with extensions</a> , which are more highly privileged than web sites. As of Chrome 92, we will start extending this capability so that extensions can no longer share processes with each other. This provides an extra line of defense against malicious extensions, without removing any existing extension capabilities.<br> Meanwhile, Site Isolation on Android currently focuses on <a rel="noreferrer" target="_blank" href="https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html">protecting only high-value sites</a> , to keep performance overheads low. Today, we are announcing two Site Isolation improvements that will protect more sites for our Android users. Starting in Chrome 92, Site Isolation will apply to sites where users log in via third-party providers, as well as sites that carry Cross-Origin-Opener-Policy headers.<br> Our ongoing goal with Site Isolation for Android is to offer additional layers of security without adversely affecting the user experience for resource-constrained devices. Site Isolation for all sites continues to be too costly for most Android devices, so our strategy is to improve heuristics for prioritizing sites that benefit most from added protection. So far, Chrome has been isolating sites where users log in by entering a password. However, many sites allow users to authenticate on a third-party site (for example, sites that offer "Sign in with Google"), possibly without the user ever typing in a password. This is most commonly accomplished with the industry-standard <a rel="noreferrer" target="_blank" href="https://oauth.net/2/">OAuth protocol</a> . Starting in Chrome 92, Site Isolation will recognize common OAuth interactions and protect sites relying on OAuth-based login, so that user data is safe however a user chooses to authenticate.<br> Additionally, Chrome will now trigger Site Isolation based on the new <a rel="noreferrer" target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy">Cross-Origin-Opener-Policy</a> (COOP) response header. Supported since Chrome 83, this header allows operators of security-conscious websites to <a rel="noreferrer" target="_blank" href="https://html.spec.whatwg.org/dev/origin.html#cross-origin-opener-policies">request a new browsing context group</a> for certain HTML documents. This allows the document to better isolate itself from untrustworthy origins, by preventing attackers from referencing or manipulating the site's top-level window. It’s also one of the headers required to use <a rel="noreferrer" target="_blank" href="https://web.dev/coop-coep/">powerful APIs</a> such as SharedArrayBuffers. Starting in Chrome 92, Site Isolation will treat non-default values of the COOP header on any document as a signal that the document's underlying site may have sensitive data and will start isolating such sites. Thus, site operators who wish to ensure their sites are protected by Site Isolation on Android can do so by serving COOP headers on their sites.<br> As before, Chrome stores newly isolated sites locally on the device and clears the list whenever users clear their browsing history or other site data. Additionally, Chrome places certain restrictions on sites isolated by COOP to keep the list focused on recently-used sites, prevent it from growing overly large, and protect it from misuse (e.g., by requiring user interaction on COOP sites before adding them to the list). We continue to require a minimum RAM threshold (currently 2GB) for these new Site Isolation modes. With these considerations in place, our data suggests that the new Site Isolation improvements do not noticeably impact Chrome's overall memory usage or performance, while protecting many additional sites with sensitive user data.<br> Given these improvements in Site Isolation on Android, we have also decided to disable <a rel="noreferrer" target="_blank" href="https://v8.dev/blog/spectre">V8 runtime mitigations</a> for Spectre on Android. These mitigations are less effective than Site Isolation and impose a performance cost. Disabling them brings Android on par with desktop platforms, where they have been turned off since Chrome 70. We advise that <a rel="noreferrer" target="_blank" href="https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html">sites wanting to protect data from Spectre should consider serving COOP headers</a> , which will in turn trigger Site Isolation.<br> Users who desire the most complete protection for their Android devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.<br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/advancing-inclusive-diverse-security.html">Advancing an inclusive, diverse security industry</a><br> <hr> Posted by Sarah Morales, Community Outreach Manager, Security It’s no secret that lack of diversity in corporate America is a well-documented problem and improvements have been slow. To help improve female representation in the cybersecurity industry, Google teamed up with ... <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/advancing-inclusive-diverse-security.html">Read More</a><br> Posted by Sarah Morales, Community Outreach Manager, Security It’s no secret that lack of diversity in corporate America is a well-documented problem and improvements have been slow. To help improve female representation in the cybersecurity industry, Google teamed up with <a rel="noreferrer" target="_blank" href="https://www.wicys.org/">Women in Cybersecurity (WiCyS)</a> and <a rel="noreferrer" target="_blank" href="https://www.sans.org/">SANS Institute</a> a year ago to establish the <a rel="noreferrer" target="_blank" href="https://www.wicys.org/benefits/security-training-scholarship/">Security Training Scholarship Program</a> . The multi-stage security training program set participants on a path to launch and advance their careers in cybersecurity through skills development, introducing them to fundamental cybersecurity concepts with interactive challenges like Capture the Flag (CTF) and the SANS CyberStart Game, which introduces topics such as Linux, web attacks, programming, forensics, and more. Mentors and peers guide the participants through each stage of the program and top qualifiers then graduate and receive access to the SANS foundational security training courses, which readies and prepares these women for their first roles in the security industry. The goal is to get them employed in cybersecurity within the next 1.5 years and to create a powerful network of women in the field – in essence, drawing more women to the industry and helping to close the talent gap. As the inaugural program comes to an end, we are proud to report that its overall impact includes:<br> 112 people received training-based scholarship<br> 15 Full Scholarship Recipients received the full course training, which includes:<br> CyberStart Game and SANS BootUp CTF<br> SANS SEC275 Foundations & Exam<br> SANS 401 Security Essentials Bootcamp and GSEC<br> Elective - SANS SEC504/GCIH, SEC488/GCLD, SEC560/GPEN, or SEC548/GWAPT<br> 24 certifications earned to date with 100% pass rate, with average score on GSEC 90%<br> Since 2013, only 2 people have scored 99% on GIAC Certified Incident Handler (GCIH) one is a WiCyS Scholarship Recipient<br> 1/3 of students were employed in direct information security roles before the program ended<br> 100% of Full Scholarship Recipients intend to have long term careers in information security (15+ years)<br> Participants praise the program’s strong networking component where they can support one another, share best practices, ask questions from SANS security experts and receive industry insight from members across Google’s security team. As Lynn Dohm, executive director of WiCyS, told us, “You cannot put a price tag on the power of community, and last year’s WiCyS Security Training Program proved just that.” Here at Google, we are inspired by the dedication and passion the scholarship recipients have shown throughout the program and are eager to see what they accomplish throughout their careers. Elizabeth Beattie, who was part of the inaugural program told us, “I learned that, as part of my scholarship program with WiCyS, SANS Institute and Google, I’ve been awarded a scholarship to attend the WiCyS 2021 conference in September. In fact, I’ve volunteered to co-author a panel there with some of my amazing fellow recipients. And the crowning achievement? Tonight, I passed my first GIAC certification (GSEC)!” Despite these great results, we know there is still a lot of work to be done to help educate and develop a more inclusive information security workforce. So this year we are expanding the Security Trainings Scholarship Program to help us reach even more women and generate a steady stream of talent in the field of information security. This expansion would not have been possible without the added support of Facebook and Bloomberg, who have come on board this year to boost this important program. “We are thrilled to scale the program this year, powered by scholarships from Google, Bloomberg, and Facebook,” said Dohm. “Now, more WiCyS members will be able to dive deep and change the trajectory of their career in less than a year, all within a cohort setting with extensive support and resources provided by mentors and colleagues. That’s what empowerment looks like, and we are thrilled that these three incredible strategic partners of WiCyS can make this happen for not only the WiCyS community, but also for the sake of the cybersecurity workforce at large.” The next round of scholarships is open through August 2, 2021. To learn more and apply, please visit the <a rel="noreferrer" target="_blank" href="https://www.wicys.org/benefits/security-training-scholarship/">WiCyS application page</a> . We can’t wait to meet the next cohort of recipients.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210715-201558/ Thu, 15 Jul 2021 20:15:57 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210715-201558/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/verifiable-design-in-modern-systems.html">Verifiable design in modern systems</a><br></p> <hr> Posted by Ryan Hurst, Production Security Team The way we design and build software is continually evolving. Just as we now think of security as something we build into software from the start, we are also increasingly looking for new ways to minimize trust in that software. One of the ways we can do that is by designing software so that you can get cryptographic certainty of what the software has done. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/verifiable-design-in-modern-systems.html">Read More</a><br> Posted by Ryan Hurst, Production Security Team<br> The way we design and build software is continually evolving. Just as we now think of security as something we build into software from the start, we are also increasingly looking for new ways to minimize trust in that software. One of the ways we can do that is by designing software so that you can get cryptographic certainty of what the software has done. In this post, we'll introduce the concept of <a rel="noreferrer" target="_blank" href="https://transparency.dev/verifiable-data-structures/">verifiable data structures</a> that help us get this cryptographic certainty. We'll describe some existing and new applications of verifiable data structures, and provide some additional resources we have created to help you use them in your own applications. A verifiable data structure is a class of data structure that lets people efficiently agree, with cryptographic certainty, that the data contained within it is correct. <a rel="noreferrer" target="_blank" href="https://artsandculture.google.com/entity/merkle-tree/m07h_v_">Merkle Trees</a> are the most famous of these and have been used for decades because they can enable efficient verification that a particular piece of data is included among many records - as a result they also form the basis of most blockchains. Although these verifiable data structures are not new, we now have a new generation of developers who have discovered them and the designs they enable -- further accelerating their adoption. These verifiable data structures enable building a new class of software that have elements of verifiability and transparency built into the way they operate. This gives us new ways to defend against coercion, introduce accountability to existing and new ecosystems, and make it easier to demonstrate compliance to regulators, customers and partners. <a rel="noreferrer" target="_blank" href="https://certificate.transparency.dev/">Certificate Transparency</a> is a great example of a non-blockchain use of these verifiable data structures at scale to secure core internet infrastructure. By using these patterns, we have been able to <a rel="noreferrer" target="_blank" href="https://certificate.transparency.dev/community/">introduce transparency and accountability</a> to an existing system used by everyone without <a rel="noreferrer" target="_blank" href="https://research.google/pubs/pub47551/">breaking the web</a> . Unfortunately, despite the capabilities of verifiable data structures and the associated patterns, there are not many resources developers can use to design, build, and deploy scalable and production-quality systems based on them. To address this gap we have generalized the <a rel="noreferrer" target="_blank" href="https://github.com/google/trillian">platform</a> we used to build Certificate Transparency so it can be applied to other classes of problems as well. Since this infrastructure has been used for years as part of this ecosystem it is well understood and can be deployed confidently in production systems. This is why we have seen solutions in areas of healthcare, financial services, and supply chain leverage this platform. Beyond that, we have also applied these patterns to bring these transparency and accountability properties to other problems within our own products and services. To this end, in 2019, we used this platform to bring supply chain integrity to the Go language ecosystem via the <a rel="noreferrer" target="_blank" href="https://www.youtube.com/watch?v=KqTySYYhPUE">Go Checksum Database</a> . This system allows developers to have confidence that the package management systems supporting the Go ecosystem can’t intentionally, arbitrarily, or accidentally start giving out the wrong code without getting caught. The reproducibility of Go builds makes this particularly powerful as it enables the developer to ensure what is in the source repository matches what is in the package management system. This solution delivers a verifiable chaiin all the way from the source repositories to the final compiled artifacts. Another example of using these patterns is our recently <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/03/introducing-sigstore-easy-code-signing.html">announced</a> partnership with the Linux Foundation on <a rel="noreferrer" target="_blank" href="https://sigstore.dev/">Sigstore</a> . This project is a response to the ever-increasing influx of supply chain attacks on the Open Source ecosystem. Supply chain attacks have been possible because there are weaknesses at every link in the chain. Components like build systems, source code management tools, and artifact repositories all need to be treated as critical production environments, because they are. To address this, we first need to make it possible to verify provenance along the entire chain and the goal of the Sigstore effort is to enable just that. We are now working on using these patterns and tools to <a rel="noreferrer" target="_blank" href="https://github.com/google/trillian-examples/tree/master/binary_transparency/firmware">enable hardware-enforced supply chain integrity for device firmware</a> , which we hope will discourage supply chain attacks on the devices, like smartphones, that we rely on every day by bringing transparency and accountability to their firmware supply chain. In all of the above examples, we are using these verifiable data structures to ensure the integrity of artifacts in the supply chain. This enables customers, auditors, and internal security teams to be confident that each actor in the supply chain has lived up to their responsibilities. This helps earn the trust of those that rely on the supply chain, discourages insiders from using their position as it increases the chance they will get caught, introduces accountability, and enables proving the associated systems continually meet their compliance obligations. When using these patterns the most important task is defining what data should be logged. This is why we put together a <a rel="noreferrer" target="_blank" href="https://transparency.dev/how-to-design-a-verifiable-system/">taxonomy and modeling framework</a> which we have found to be helpful in designing verifiability into the systems we discussed above, and which we hope you will find valuable too. Please take a look at the <a rel="noreferrer" target="_blank" href="http://transparency.dev/">transparency.dev</a> website to learn about these verifiable data structures, and the tools and guidance we have put together to help use them in your own applications.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210701-161458/ Thu, 01 Jul 2021 16:14:56 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210701-161458/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/measuring-security-risks-in-open-source.html">Measuring Security Risks in Open Source Software: Scorecards Launches V2</a><br></p> <hr> Posted by Kim Lewandowski, Azeem Shaikh, Laurent Simon, Google Open Source Security Team <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/07/measuring-security-risks-in-open-source.html">Read More</a><br> Posted by Kim Lewandowski, Azeem Shaikh, Laurent Simon, Google Open Source Security Team<br> Contributors to the <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard">Scorecards project</a> , an automated security tool that produces a “risk score” for open source projects, have accomplished a lot since <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2020/11/security-scorecards-for-open-source.html">our launch last fall.</a> Today, in collaboration with the <a rel="noreferrer" target="_blank" href="https://openssf.org/">Open Source Security Foundation</a> community, we are announcing <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/releases/tag/v2.0.0">Scorecards v2</a> . We have added new security checks, scaled up the number of projects being scored, and made this data easily accessible for analysis. With so much software today relying on open-source projects, consumers need an easy way to judge whether their dependencies are safe. Scorecards helps reduce the toil and manual effort required to continually evaluate changing packages when maintaining a project’s supply chain. Consumers can automatically assess the risks that dependencies introduce and use this data to make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.<br> Identifying Risks<br> Since last fall, Scorecards’ coverage has grown; we've added several new checks, following the <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html">Know, Prevent, Fix framework</a> proposed by Google earlier this year, to prioritize our additions:<br> Malicious contributors Contributors with malicious intent or compromised accounts can introduce potential backdoors into code. Code reviews help mitigate against such attacks. With the new <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#branch-protection">Branch-Protection</a> check, developers can verify that the project enforces mandatory code review from another developer before code is committed. Currently, this check can only be run by a repository admin due to GitHub API limitations. For a third-party repository, use the less informative <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#code-review">Code-Review</a> check instead.<br> Vulnerable code Despite best efforts by developers and peer reviews, vulnerable code can enter source control and remain undetected. That’s why it's important to enable continuous fuzzing and static code analysis to catch bugs early in the development lifecycle. We have added checks to detect if a project uses <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#fuzzing">Fuzzing</a> and <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#sast">SAST</a> tools as part of their CI/CD system.<br> Build system compromise A common CI/CD solution used by GitHub projects is <a rel="noreferrer" target="_blank" href="https://github.com/features/actions">GitHub Actions</a> . A danger with these action workflows is that they may handle untrusted user input. Meaning, an attacker can craft a malicious pull request to gain access to the privileged GitHub token, and with it the ability to <a rel="noreferrer" target="_blank" href="https://www.bleepingcomputer.com/news/security/heres-how-a-researcher-broke-into-microsoft-vs-codes-github/">push malicious code to the repo</a> without review. To mitigate this risk, Scorecard's <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#token-permissions">Token-Permissions</a> prevention check now verifies that the GitHub workflows follow the principle of least privilege by making GitHub tokens read-only by default.<br> Bad dependencies Any software is as secure as its weakest dependency. This may sound obvious, but the first step to knowing our dependencies is simply to declare them... and have our dependencies declare them too. Once we have this provenance information, we can assess the risks of our software and mitigate those risks. Unfortunately, there are several widely-used anti-patterns that break this provenance principle. The first of these anti-patterns is checked-in binaries -- as there's no way to easily verify or check the contents of the binary in the project. Scorecards provides <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#binary-artifacts">Binary-Artifacts</a> check for testing this. Another anti-pattern is the use of curl | bash in scripts which dynamically pulls dependencies. Cryptographic hashes let us pin our dependencies to a known value: if this value ever changes, the build system will detect it and refuse to build. Pinning dependencies is useful everywhere we have dependencies: not just during compilation, but also in Dockerfiles, CI/CD workflows, etc. Scorecards checks for these anti-patterns with the <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#frozen-deps">Frozen-Deps</a> check. This check is helpful for mitigating against malicious dependency attacks such as the recent <a rel="noreferrer" target="_blank" href="https://about.codecov.io/security-update/">CodeCov</a> attack. Even with hash-pinning, hashes need to be updated once in a while when dependencies patch vulnerabilities. Tools like <a rel="noreferrer" target="_blank" href="https://docs.github.com/en/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/configuring-dependabot-security-updates">dependabot</a> or <a rel="noreferrer" target="_blank" href="https://github.com/renovatebot/renovate">renovatebot</a> give us the opportunity to review and update the hashes. The Scorecards <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#automatic-dependency-update">Automated-Dependency-Update</a> check verifies that developers rely on such tools to update their dependencies. It is important to know vulnerabilities in a project before uptaking it as a dependency. Scorecards can provide this information via the new <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/checks/checks.md#vulnerabilities">Vulnerabilities</a> check, without the need to subscribe to a vulnerability alert system.<br> Scaling the impact<br> To date, the Scorecards project has scaled up to evaluate security criteria for over <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/cron/data/projects.csv">50,000</a> open source projects. In order to scale this project, we undertook a massive redesign of our architecture and used a PubSub model which achieved horizontal scalability and higher throughput. This fully automated tool periodically evaluates critical open source projects and exposes the Scorecards check information through a <a rel="noreferrer" target="_blank" href="https://console.cloud.google.com/bigquery?p=openssf&page=table&d=scorecardcron&t=scorecard">public BigQuery dataset</a> which is refreshed weekly.<br> This data can be retrieved using the <a rel="noreferrer" target="_blank" href="https://cloud.google.com/bigquery/docs/reference/bq-cli-reference">bq command line tool</a> . The following example shows how to export data for the Kubernetes project. Substitute the url for the repo to export data from a different project:<br> $ bq query --nouse_legacy_sql 'SELECT Repo, Date, Checks FROM openssf.scorecardcron.scorecard_latest WHERE Repo="github.com/kubernetes/kubernetes"'<br> To export the latest data on all analyzed projects, see instructions <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard#public-data">here</a> .<br> How does the internet measure up?<br> Scorecards data for available projects is now included in the recently <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2021/06/introducing-open-source-insights-project.html">announced</a> Google Open Source Insights <a rel="noreferrer" target="_blank" href="https://deps.dev/">project</a> and also showcased in <a rel="noreferrer" target="_blank" href="http://metrics.openssf.org/">OpenSSF Security Metrics project</a> . The data on these sites shows that there are still important security gaps to fill, even in widely used packages <a rel="noreferrer" target="_blank" href="https://deps.dev/go/k8s.io%2Fkubernetes">like Kubernetes</a> . We also analyzed Scorecards data through Google Data Studio -- one of our data analysis and visualization tools.The diagram below shows a breakdown of the checks that were run and the pass/fail outcome for the 50,000 repositories:<br> As we can see, a lot needs to be done to improve the security of these critical projects. A large number of these projects are not continuously <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-fuzz">fuzzed</a> , do not define a security policy for reporting vulnerabilities, and do not pin dependencies, to name just a few common problems. We all need to come together as an industry to drive awareness of these widespread security risks, and to make improvements that will benefit everyone.<br> Scorecards in Action<br> Several large projects have adopted Scorecards and are keeping us updated on their experiences with it. Below are some examples of Scorecards in action:<br> Envoy Early on we <a rel="noreferrer" target="_blank" href="https://blog.envoyproxy.io/security-scorecards-envoy-automating-supply-chain-analysis-7b8fd9829169">talked</a> about how the Envoy maintainers adopted Scorecards for their project and integrated it within their policy on introducing new dependencies. Since then, pull requests introducing new dependencies to Envoy must get approval from a dependency maintainer who uses Scorecards to <a rel="noreferrer" target="_blank" href="https://github.com/envoyproxy/envoy/blob/main/DEPENDENCY_POLICY.md#new-external-dependencies">evaluate</a> the dependency against a set of criteria. In addition, Envoy also got right to work in improving its own security health metrics according to its own Scorecards evaluation, and is now pinning C++ dependencies and <a rel="noreferrer" target="_blank" href="https://github.com/envoyproxy/envoy/issues/12951">requiring</a> pip hashes for python dependencies. <a rel="noreferrer" target="_blank" href="https://github.com/envoyproxy/envoy/issues/16579">Github actions</a> are also pinned in the continuous integration flow. Previously, Envoy had created a <a rel="noreferrer" target="_blank" href="https://github.com/envoyproxy/envoy/blob/main/tools/dependency/ossf_scorecard.py">tool</a> that outputs Scorecards data on its dependencies as a CSV that can be used to generate a table of results:<br> Now with more project data, Envoy is able to automatically generate up-to-date Scorecard information about its dependencies and publish it in <a rel="noreferrer" target="_blank" href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/external_deps">documentation</a> , like the following:<br> Scorecards We improved our own score for the Scorecards! For example, we are now pinning our own dependencies by hash (e.g. <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commit/3b1c9b8496a7ff8dad8506691fa28f2d60b14a90">docker dependencies</a> , <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commit/6367cc44f6a1d8318e452761253f2935b1becd4a">workflow dependencies</a> ) to prevent <a rel="noreferrer" target="_blank" href="https://about.codecov.io/security-update/">CodeCov</a> style attacks. We’ve also included a <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/SECURITY.md">Security Policy</a> based on this <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-vulnerability-guide">recommended template</a> .<br> We look forward to continuing to grow the Scorecards community. The project now has contributions from <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/graphs/contributors">23</a> developers. Thank you to <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commits?author=azeemshaikh38">Azeem</a> , <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commits?author=naveensrinivasan">Naveen</a> , <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commits?author=laurentsimon">Laurent</a> , <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commits?author=asraa">Asra</a> and <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/commits?author=chrismcgehee">Chris</a> for their work building these new features and scaling Scorecards. If you would like to join the fun, check out these good first timer <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/issues">issues</a> . If you would like us to help you run Scorecards on specific projects, please submit a GitHub pull request to add those projects <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/blob/main/cron/data/projects.csv">here</a> . Last but not least, we have a lot of ideas and <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/issues?q=is%3Aopen+is%3Aissue+%22new+check%3A%22">many more checks we’d like to add</a> , but we want to hear from you. Tell us which checks you would like to see in the next version of Scorecards.<br> What’s next?<br> There are a couple of big enhancements we’re especially excited about:<br> <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/issues/271">Scorecards Badges</a> - GitHub badges to show off compliance<br> <a rel="noreferrer" target="_blank" href="https://github.com/ossf/scorecard/issues/193">Integration with CI/CD and GitHub Code Scanning Results</a><br> <hr> <a rel="noreferrer" target="_blank" href="https://github.com/ossf/allstar">Integration with Allstar project</a> - GitHub App for enforcing security policies<br> Thanks again to the entire Scorecards community and the OpenSSF for making this project successful. If you’re adopting and improving the score of the projects you maintain, <a rel="noreferrer" target="_blank" href="https://slack.openssf.org/#security_scorecards">tell us</a> about it. Until next time, keep on improving those scores!<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210701-001522/ Thu, 01 Jul 2021 00:15:21 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210701-001522/ SLSA 1 requires that the build process be fully scripted/automated and generate provenance. Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies. Knowing the provenance allows software consumers to make risk-based security decisions. Though provenance at SLSA 1 does not protect against tampering, it offers a basic level of code source identification and may aid in vulnerability management. SLSA 2 requires using version control and a hosted build service that generates authenticated provenance. These additional requirements give the consumer greater confidence in the origin of the software. At this level, the provenance prevents tampering to the extent that the build service is trusted. SLSA 2 also provides an easy upgrade path to SLSA 3. SLSA 3 further requires that the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance, respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination. SLSA 4 is currently the highest level, requiring two-person review of all changes and a hermetic, reproducible build process. Two-person review is an industry best practice for catching mistakes and deterring bad behavior. Hermetic builds guarantee that the provenance’s list of dependencies is complete. Reproducible builds, though not strictly required, provide many auditability and reliability benefits. Overall, SLSA 4 gives the consumer a high degree of confidence that the software has not been tampered with. More details on these proposed levels can be found in the <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa">GitHub repository</a> , including the corresponding Source and Build/Provenance <a rel="noreferrer" target="_blank" href="https://slsa.dev/">requirements</a> . We are open to feedback and suggestions for changes on these requirements.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210625-001722/ Fri, 25 Jun 2021 00:17:21 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210625-001722/ In recent months, Google has launched <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html">several efforts</a> to strengthen open-source security on multiple fronts. One important focus is improving how we identify and respond to known security vulnerabilities without doing extensive manual work. It is essential to have a precise common data format to triage and remediate security vulnerabilities, particularly when communicating about risks to affected dependencies—it enables easier automation and empowers consumers of open-source software to know when they are impacted and make security fixes as soon as possible. We released the <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2021/02/launching-osv-better-vulnerability.html">Open Source Vulnerabilities (OSV) database</a> in February with the goal of automating and improving vulnerability triage for developers and users of open source software. This initial effort was bootstrapped with a dataset of a few thousand vulnerabilities from the <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-fuzz">OSS-Fuzz</a> project. Implementing OSV to communicate precise vulnerability data for hundreds of critical open-source projects proved the success and utility of the format, and garnered feedback to help us improve the project; for example, we dropped the Cloud API key requirement, making the database even easier to access by more users. The community response also showed that there was broad interest in extending the effort further. Today, we’re excited to announce a new milestone in expanding OSV to several key open-source ecosystems: <a rel="noreferrer" target="_blank" href="https://github.com/golang/vulndb">Go</a> , <a rel="noreferrer" target="_blank" href="https://github.com/RustSec/advisory-db">Rust</a> , <a rel="noreferrer" target="_blank" href="https://github.com/pypa/advisory-db">Python</a> , and <a rel="noreferrer" target="_blank" href="https://github.com/distributedweaknessfiling/dwflist">DWF</a> . This expansion unites and aggregates four important vulnerability databases, giving software developers a better way to track and remediate the security issues that affect them. Our effort also aligns with the recent <a rel="noreferrer" target="_blank" href="https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity">US Executive Order on Improving the Nation’s Cybersecurity</a> , which emphasized the need to remove barriers to sharing threat information in order to strengthen national infrastructure. This expanded shared vulnerability database marks an important step toward creating a more secure open-source environment for all users.<br> A simple, unified schema for describing vulnerabilities precisely As with open source development, vulnerability databases in open source follow a distributed model, with many ecosystems and organizations creating their own database. Since each uses their own format to describe vulnerabilities, a client tracking vulnerabilities across multiple databases must handle each completely separately. Sharing of vulnerabilities between databases is also difficult. The Google Open Source Security team, Go team, and the broader open-source community have been developing a simple <a rel="noreferrer" target="_blank" href="https://tinyurl.com/vuln-json">vulnerability interchange schema</a> for describing vulnerabilities that’s designed from the beginning for open-source ecosystems. After starting work on the schema a few months ago, we <a rel="noreferrer" target="_blank" href="http://tinyurl.com/vuln-json">requested public feedback and received hundreds of comments</a> . We have incorporated the input from readers to arrive at the current schema:<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210624-161607/ Thu, 24 Jun 2021 16:16:05 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210624-161607/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html">Announcing a unified vulnerability schema for open source</a><br></p> <hr> Posted by Oliver Chang, Google Open Source Security team and Russ Cox, Go team<br> In recent months, Google has launched <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html">several efforts</a> to strengthen open-source security on multiple fronts. One important focus is improving how we identify and respond to known security vulnerabilities without doing extensive manual work. It is essential to have a precise common data format to triage and remediate security vulnerabilities, particularly when communicating about risks to affected dependencies—it enables easier automation and empowers consumers of open-source software to know when they are impacted and make security fixes as soon as possible. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/announcing-unified-vulnerability-schema.html">Read More</a><br> In recent months, Google has launched <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html">several efforts</a> to strengthen open-source security on multiple fronts. One important focus is improving how we identify and respond to known security vulnerabilities without doing extensive manual work. It is essential to have a precise common data format to triage and remediate security vulnerabilities, particularly when communicating about risks to affected dependencies—it enables easier automation and empowers consumers of open-source software to know when they are impacted and make security fixes as soon as possible. We released the <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2021/02/launching-osv-better-vulnerability.html">Open Source Vulnerabilities (OSV) database</a> in February with the goal of automating and improving vulnerability triage for developers and users of open source software. This initial effort was bootstrapped with a dataset of a few thousand vulnerabilities from the <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-fuzz">OSS-Fuzz</a> project. Implementing OSV to communicate precise vulnerability data for hundreds of critical open-source projects proved the success and utility of the format, and garnered feedback to help us improve the project; for example, we dropped the Cloud API key requirement, making the database even easier to access by more users. The community response also showed that there was broad interest in extending the effort further. Today, we’re excited to announce a new milestone in expanding OSV to several key open-source ecosystems: <a rel="noreferrer" target="_blank" href="https://github.com/golang/vulndb">Go</a> , <a rel="noreferrer" target="_blank" href="https://github.com/RustSec/advisory-db">Rust</a> , <a rel="noreferrer" target="_blank" href="https://github.com/pypa/advisory-db">Python</a> , and <a rel="noreferrer" target="_blank" href="https://github.com/distributedweaknessfiling/dwflist">DWF</a> . This expansion unites and aggregates four important vulnerability databases, giving software developers a better way to track and remediate the security issues that affect them. Our effort also aligns with the recent <a rel="noreferrer" target="_blank" href="https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity">US Executive Order on Improving the Nation’s Cybersecurity</a> , which emphasized the need to remove barriers to sharing threat information in order to strengthen national infrastructure. This expanded shared vulnerability database marks an important step toward creating a more secure open-source environment for all users. A simple, unified schema for describing vulnerabilities precisely As with open source development, vulnerability databases in open source follow a distributed model, with many ecosystems and organizations creating their own database. Since each uses their own format to describe vulnerabilities, a client tracking vulnerabilities across multiple databases must handle each completely separately. Sharing of vulnerabilities between databases is also difficult. The Google Open Source Security team, Go team, and the broader open-source community have been developing a simple <a rel="noreferrer" target="_blank" href="https://tinyurl.com/vuln-json">vulnerability interchange schema</a> for describing vulnerabilities that’s designed from the beginning for open-source ecosystems. After starting work on the schema a few months ago, we <a rel="noreferrer" target="_blank" href="http://tinyurl.com/vuln-json">requested public feedback and received hundreds of comments</a> . We have incorporated the input from readers to arrive at the current schema:<br> {<br> "id" : string ,<br> "modified" : string ,<br> "published" : string ,<br> "withdrawn" : string ,<br> "aliases" : [ string ],<br> "related" : [ string ],<br> "package" : {<br> "ecosystem" : string ,<br> "name" : string ,<br> "purl" : string ,<br> },<br> "summary" : string ,<br> "details" : string ,<br> "affects" : [ {<br> "ranges" : [ {<br> "type" : string ,<br> "repo" : string ,<br> "introduced" : string ,<br> "fixed" : string<br> } ],<br> "versions" : [ string ]<br> "references" : [ {<br> "url" : string<br> "ecosystem_specific" : { see spec },<br> "database_specific" : { see spec },<br> }<br> This new vulnerability schema aims to address some key problems with managing vulnerabilities in open source. We found that there was no existing standard format which:<br> Enforces version specification that precisely matches naming and versioning schemes used in actual open source package ecosystems. For instance, matching a vulnerability such as a <a rel="noreferrer" target="_blank" href="https://cve.mitre.org/">CVE</a> to a package name and set of versions in a package manager is difficult to do in an automated way using existing mechanisms such as <a rel="noreferrer" target="_blank" href="https://nvd.nist.gov/products/cpe">CPEs</a> .<br> Can be used to describe vulnerabilities in any open source ecosystem, while not requiring ecosystem-dependent logic to process them.<br> Is easy to use by both automated systems and humans.<br> With this schema we hope to define a format that all vulnerability databases can export. A unified format means that vulnerability databases, open source users, and security researchers can easily share tooling and consume vulnerabilities across all of open source. This means a more complete view of vulnerabilities in open source for everyone, as well as faster detection and remediation times resulting from easier automation.<br> The current state<br> The <a rel="noreferrer" target="_blank" href="https://tinyurl.com/vuln-json">vulnerability schema spec</a> has gone through several iterations, and we are inviting further feedback as it gets closer to finalized. A number of public vulnerability databases today are already exporting this format, with more in the pipeline:<br> <a rel="noreferrer" target="_blank" href="https://github.com/golang/vulndb">Go vulnerability database</a> for Go packages<br> <a rel="noreferrer" target="_blank" href="https://github.com/RustSec/advisory-db">Rust advisory database</a> for Cargo packages<br> <a rel="noreferrer" target="_blank" href="https://github.com/pypa/advisory-db">Python advisory database</a> for PyPI packages<br> <a rel="noreferrer" target="_blank" href="https://github.com/distributedweaknessfiling/dwflist">DWF database</a> for vulnerabilities in the Linux kernel and other popular software<br> <a rel="noreferrer" target="_blank" href="https://github.com/google/oss-fuzz-vulns">OSS-Fuzz database</a> for vulnerabilities in C/C++ software found by OSS-Fuzz<br> The OSV service has also aggregated all of these vulnerability databases, which are viewable at our <a rel="noreferrer" target="_blank" href="https://osv.dev/list">web UI</a> . They can also be queried with a single command via the same <a rel="noreferrer" target="_blank" href="https://osv.dev/docs/#tag/api">existing APIs</a> :<br> curl - X POST - d \<br> '{"commit": "a46c08c533cfdf10260e74e2c03fa84a13b6c456"}' \<br> "https://api.osv.dev/v1/query"<br> '{"version": "2.4.1", "package": {"name": "jinja2", "ecosystem": "PyPI"}}' \<br> Automating vulnerability database maintenance<br> Producing quality vulnerability data is also difficult. In addition to <a rel="noreferrer" target="_blank" href="https://opensource.googleblog.com/2021/02/launching-osv-better-vulnerability.html">OSV’s existing automation</a> , we built more <a rel="noreferrer" target="_blank" href="https://github.com/google/osv/tree/master/vulnfeeds">automation tools</a> for vulnerability database maintenance, and used these tools to <a rel="noreferrer" target="_blank" href="https://discuss.python.org/t/proposing-a-community-maintained-database-of-pypi-package-vulnerabilities/8374/13">bootstrap</a> the community <a rel="noreferrer" target="_blank" href="https://github.com/pypa/advisory-db">Python advisory database</a> . This automation takes existing feeds, accurately matches them to packages, and <a rel="noreferrer" target="_blank" href="https://github.com/pypa/advisory-db/commit/7afe2510b693ad60a0b95da8a5b2a370a7c48997">generates entries</a> containing <a rel="noreferrer" target="_blank" href="https://github.com/pypa/advisory-db/commit/e4035d8131324cf207ac9b40eacac79b97b1c6b2">precise, validated version ranges</a> with minimal human intervention. We plan to extend this tooling to other ecosystems for which there is no existing vulnerability database, or little support for ongoing database maintenance.<br> Get involved<br> Thank you to all the open source developers who have provided feedback and adopted this format. We’re continuing to work with open source communities to develop this further and earn more widespread adoption in all ecosystems. If you are interested in adopting this format, we’d appreciate any feedback on our <a rel="noreferrer" target="_blank" href="https://tinyurl.com/vuln-json">public spec</a> .<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Open%20Source">Open Source</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/vulnerabilities">vulnerabilities</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210618-161505/ Fri, 18 Jun 2021 16:15:04 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210618-161505/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/get-ready-for-2021-google-ctf.html">Get ready for the 2021 Google CTF</a><br></p> <hr> Posted by Kristoffer Janke, Information Security Engineer<br> Are you ready for no sleep, no chill and a lot of hacking? Our annual Google CTF is back! The competition kicks off on Saturday July 17 00:00:01 AM UTC and runs through Sunday July 18 23:59:59 UTC. Teams can register at <a rel="noreferrer" target="_blank" href="http://goo.gle/ctf">http://goo.gle/ctf</a> . Just like last year, the top 16 teams will qualify for our <a rel="noreferrer" target="_blank" href="https://capturetheflag.withgoogle.com/hackceler8#about">Hackceler8</a> speed run and the chance to take home a total of $30,301.70 in prize money.<br> As we reminisce on last years event, we’d be remiss if we didn’t recognize our 2020 winning teams:<br> Plaid Parliament of Pwning<br> I Use Bing<br> pasten<br> The Flat Network Society<br> We are eager to see if they can defend their leet status. For those interested, we have published all 2020 Hackceler8 videos for your viewing pleasure <a rel="noreferrer" target="_blank" href="http://goo.gle/hackceler8">here.</a> Whether you’re a seasoned CTF player or just curious about cyber security and ethical hacking, we want you to join us. Sign up to learn skills, meet new friends in the security community and even watch the pros in action. For the latest announcements, see g.co/ctf, subscribe to our mailing list or follow us on <a rel="noreferrer" target="_blank" href="https://twitter.com/GoogleVRP">@GoogleVRP</a> . See you there! P.S. Curious about last year’s Google CTF challenges? We open-sourced them <a rel="noreferrer" target="_blank" href="https://github.com/google/google-ctf/tree/master/2020/quals">here</a> .<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/CTF">CTF</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a><br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/CTF">CTF</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210616-161504/ Wed, 16 Jun 2021 16:15:03 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210616-161504/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html">Introducing SLSA, an End-to-End Framework for Supply Chain Integrity</a><br></p> <hr> Posted Kim Lewandowski, Google Open Source Security Team & Mark Lodato, Binary Authorization for Borg Team <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html">Read More</a><br> Posted Kim Lewandowski, Google Open Source Security Team & Mark Lodato, Binary Authorization for Borg Team<br> Supply chain integrity attacks—unauthorized modifications to software packages—have been <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">on the rise</a> in the past two years, and are proving to be common and reliable attack vectors that affect all consumers of software. The software development and deployment supply chain is quite complicated, with numerous threats along the source ➞ build ➞ publish workflow. While point solutions do exist for some specific vulnerabilities, there is no comprehensive end-to-end framework that both defines how to mitigate threats across the software supply chain, and provides reasonable security guarantees. There is an urgent need for a solution in the face of the eye-opening, multi-billion dollar attacks in recent months (e.g. <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">SolarWinds</a> , <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Codecov</a> ), some of which could have been prevented or made more difficult had such a framework been adopted by software developers and consumers. Our proposed solution is <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Supply chain Levels for Software Artifacts</a> (SLSA, pronounced “salsa”), an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. It is inspired by Google’s internal “ <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Binary Authorization for Borg</a> ” which has been in use for the past 8+ years and is mandatory for all of Google's production workloads. The goal of SLSA is to improve the state of the industry, particularly open source, to defend against the most pressing integrity threats. With SLSA, consumers can make informed choices about the security posture of the software they consume.<br> How SLSA helps SLSA helps to protect against common supply chain attacks. The following image illustrates a typical software supply chain and includes examples of attacks that can occur at every link in the chain. Each type of attack has occured over the past several years and, unfortunately, is increasing as time goes on.<br> Threat<br> Known example<br> How SLSA could have helped<br> Submit bad code to the source repository<br> <a rel="noreferrer" target="_blank" href="https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/">Linux hypocrite commits</a> : Researcher attempted to intentionally introduce vulnerabilities into the Linux kernel via patches on the mailing list.<br> Two-person review caught most, but not all, of the vulnerabilities.<br> B<br> Compromise source control platform<br> <a rel="noreferrer" target="_blank" href="https://news-web.php.net/php.internals/113838">PHP</a> : Attacker compromised PHP’s self-hosted git server and injected two malicious commits.<br> A better-protected source code platform would have been a much harder target for the attackers.<br> C<br> Build with official process but from code not matching source control<br> <a rel="noreferrer" target="_blank" href="https://www.webmin.com/exploit.html">Webmin</a> : Attacker modified the build infrastructure to use source files not matching source control.<br> A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering.<br> D<br> Compromise build platform<br> <a rel="noreferrer" target="_blank" href="https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/">SolarWinds</a> : Attacker compromised the build platform and installed an implant that injected malicious behavior during each build.<br> Higher SLSA levels require <a rel="noreferrer" target="_blank" href="https://github.com/slsa-framework/slsa/blob/main/build-requirements.md">stronger security controls for the build platform</a> , making it more difficult to compromise and gain persistence.<br> E<br> Use bad dependency (i.e. A-H, recursively)<br> <a rel="noreferrer" target="_blank" href="https://schneider.dev/blog/event-stream-vulnerability-explained/">event-stream</a> : Attacker added an innocuous dependency and then updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F).<br> Applying SLSA recursively to all dependencies would have prevented this particular vector, because the provenance would have indicated that it either wasn’t built from a proper builder or that the source did not come from GitHub.<br> F<br> Upload an artifact that was not built by the CI/CD system<br> <a rel="noreferrer" target="_blank" href="https://about.codecov.io/apr-2021-post-mortem/">CodeCov</a> : Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly.<br> Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo.<br> G<br> Compromise package repository<br> <a rel="noreferrer" target="_blank" href="https://theupdateframework.io/papers/attacks-on-package-managers-ccs2008.pdf">Attacks on Package Mirrors</a> : Researcher ran mirrors for several popular package repositories, which could have been used to serve malicious packages.<br> Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo.<br> H<br> Trick consumer into using bad package<br> <a rel="noreferrer" target="_blank" href="https://blog.sonatype.com/damaging-linux-mac-malware-bundled-within-browserify-npm-brandjack-attempt">Browserify typosquatting</a> : Attacker uploaded a malicious package with a similar name as the original.<br> SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions.<br> What is SLSA In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus. In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give "SLSA certification" to a particular package or build platform. SLSA is designed to be incremental and actionable, and to provide security benefits at every step. Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source—something that is difficult, if not impossible, to do with most software today. SLSA consists of four levels, with SLSA 4 representing the ideal end state. The lower levels represent incremental milestones with corresponding incremental integrity guarantees. The requirements are currently defined as follows.<br> SLSA 1 requires that the build process be fully scripted/automated and generate provenance. Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies. Knowing the provenance allows software consumers to make risk-based security decisions. Though provenance at SLSA 1 does not protect against tampering, it offers a basic level of code source identification and may aid in vulnerability management. SLSA 2 requires using version control and a hosted build service that generates authenticated provenance. These additional requirements give the consumer greater confidence in the origin of the software. At this level, the provenance prevents tampering to the extent that the build service is trusted. SLSA 2 also provides an easy upgrade path to SLSA 3. SLSA 3 further requires that the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance, respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination. SLSA 4 is currently the highest level, requiring two-person review of all changes and a hermetic, reproducible build process. Two-person review is an industry best practice for catching mistakes and deterring bad behavior. Hermetic builds guarantee that the provenance’s list of dependencies is complete. Reproducible builds, though not strictly required, provide many auditability and reliability benefits. Overall, SLSA 4 gives the consumer a high degree of confidence that the software has not been tampered with. More details on these proposed levels can be found in the <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">GitHub repository</a> , including the corresponding <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Source</a> and <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Build/Provenance</a> requirements. We are open to feedback and suggestions for changes on these requirements.<br> Proof of Concept Today, we are releasing a proof of concept for SLSA 1 provenance generator ( <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">repo</a> , <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">marketplace</a> ). This will allow a user to create and upload provenance alongside their build artifacts, thereby achieving SLSA 1. To use it, add the following snippet to your workflow:<br> - name : Generate provenance<br> uses : slsa - framework / github - actions - demo@v0 . 1<br> with :<br> artifact_path : < path - to - artifact/directory ><br> Going forward, we plan to work with popular source, build, and packaging platforms to make it as easy as possible to reach higher levels of SLSA. These plans include generating provenance automatically in build systems, propagating provenance natively in package repositories, and adding security features across the major platforms. Our long-term goal is to raise the security bar across the industry so that the default expectation is higher-level SLSA security standards, with minimal effort on the part of software producers.<br> Summary SLSA is a practical framework for end-to-end software supply chain integrity, based on a model proven to work at scale in one of the world’s largest software engineering organizations. Achieving the highest level of SLSA for most projects may be difficult, but incremental improvements recognized by lower SLSA levels will already go a long way toward improving the security of the open source ecosystem. We look forward to working with the community on refining the levels as we begin adopting SLSA for our own open source projects. If you are a project maintainer and interested in trying to adopt and provide feedback on SLSA, please <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">reach out</a> or come join the discussions taking place in the <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">OpenSSF Digital Identity Attestation Working Group</a> . Check out the <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Know, Prevent, Fix</a> post to read more about Google’s overall approach to open source security.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Open%20Source">Open Source</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210609-041507/ Wed, 09 Jun 2021 04:15:05 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210609-041507/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/rustc-interop-in-android-platform.html">Rust/C++ interop in the Android Platform</a><br></p> <hr> Posted by Joel Galenson and Matthew Maurer, Android Team<br> One of the main challenges of evaluating Rust for use within the Android platform was ensuring we could provide sufficient interoperability with our existing codebase. If Rust is to meet its goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. To accomplish this, we need to provide the majority of functionality platform developers use. As we discussed <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/04/rust-in-android-platform.html">previously</a> , we have too much C++ to consider ignoring it, rewriting all of it is infeasible, and rewriting older code would likely be counterproductive as the bugs in that code have largely been fixed. This means interoperability is the most practical way forward.<br> Before introducing Rust into the Android Open Source Project (AOSP), we needed to demonstrate that Rust interoperability with C and C++ is sufficient for practical, convenient, and safe use within Android. Adding a new language has costs; we needed to demonstrate that Rust would be able to scale across the codebase and meet its potential in order to justify those costs. This post will cover the analysis we did more than a year ago while we evaluated Rust for use in Android. We also present a follow-up analysis with some insights into how the original analysis has held up as Android projects have adopted Rust.<br> Language interoperability in Android<br> Existing language interoperability in Android focuses on well defined foreign-function interface (FFI) boundaries, which is where code written in one programming language calls into code written in a different language. Rust support will likewise focus on the FFI boundary as this is consistent with how AOSP projects are developed, how code is shared, and how dependencies are managed. For Rust interoperability with C, the C application binary interface (ABI) is already sufficient.<br> Interoperability with C++ is more challenging and is the focus of this post. While both Rust and C++ support using the C ABI, it is not sufficient for idiomatic usage of either language. Simply enumerating the features of each language results in an unsurprising conclusion: many concepts are not easily translatable, nor do we necessarily want them to be. After all, we’re introducing Rust because many features and characteristics of C++ make it difficult to write safe and correct code. Therefore, our goal is not to consider all language features, but rather to analyze how Android uses C++ and ensure that interop is convenient for the vast majority of our use cases.<br> We analyzed code and interfaces in the Android platform specifically, not codebases in general. While this means our specific conclusions may not be accurate for other codebases, we hope the methodology can help others to make a more informed decision about introducing Rust into their large codebase. Our colleagues on the Chrome browser team have done a similar analysis, which you can find <a rel="noreferrer" target="_blank" href="https://www.chromium.org/Home/chromium-security/memory-safety/rust-and-c-interoperability">here</a> .<br> This analysis was not originally intended to be published outside of Google: our goal was to make a data-driven decision on whether or not Rust was a good choice for systems development in Android. While the analysis is intended to be accurate and actionable, it was never intended to be comprehensive, and we’ve pointed out a couple of areas where it could be more complete. However, we also note that initial investigations into these areas showed that they would not significantly impact the results, which is why we decided to not invest the additional effort.<br> Methodology<br> Exported functions from Rust and C++ libraries are where we consider interop to be essential. Our goals are simple:<br> Rust must be able to call functions from C++ libraries and vice versa.<br> FFI should require a minimum of <a rel="noreferrer" target="_blank" href="https://en.wikipedia.org/wiki/Boilerplate_code">boilerplate</a> .<br> FFI should not require deep expertise.<br> While making Rust functions callable from C++ is a goal, this analysis focuses on making C++ functions available to Rust so that new Rust code can be added while taking advantage of existing implementations in C++. To that end, we look at exported C++ functions and consider existing and planned compatibility with Rust via the C ABI and compatibility libraries. Types are extracted by running<br> objdump<br> on shared libraries to find external C++ functions they use <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn1">1</a> and running<br> c++filt<br> to parse the C++ types. This gives functions and their arguments. It does not consider return values, but a preliminary analysis <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn2">2</a> of those revealed that they would not significantly affect the results.<br> We then classify each of these types into one of the following buckets:<br> Supported by bindgen<br> These are generally simple types involving primitives (including pointers and references to them). For these types, Rust’s existing FFI will handle them correctly, and Android’s build system will <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/selinux/libselinux/Android.bp;l=268;drc=f30e6ff37683d72b65c160a808f87fe356c71c0b">auto-generate the bindings</a> .<br> Supported by cxx compat crate<br> These are handled by the <a rel="noreferrer" target="_blank" href="https://cxx.rs/">cxx</a> crate. This currently includes<br> std::string<br> ,<br> std::vector,<br> and C++ methods (including pointers/references to these types). Users simply have to <a rel="noreferrer" target="_blank" href="https://cxx.rs/index.html#example">define</a> the types and functions they want to share across languages and cxx will generate the code to do that safely.<br> Native support<br> These types are not directly supported, but the interfaces that use them have been manually reworked to add Rust support. Specifically, this includes types used by <a rel="noreferrer" target="_blank" href="https://android-review.googlesource.com/c/platform/system/tools/aidl/+/1357705">AIDL</a> and <a rel="noreferrer" target="_blank" href="https://android-review.googlesource.com/c/platform/build/soong/+/1412889">protobufs</a> .<br> We have also implemented a native interface for <a rel="noreferrer" target="_blank" href="https://android-review.googlesource.com/c/platform/frameworks/proto_logging/+/1592771">StatsD</a> as the existing C++ interface relies on method overloading, which is not well supported by bindgen and cxx <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn3">3</a> . Usage of this system does not show up in the analysis because the C++ API does not use any unique types.<br> Potential addition to cxx<br> This is currently common data structures such as<br> <a rel="noreferrer" target="_blank" href="https://github.com/dtolnay/cxx/issues/87">std::optional</a><br> <hr> and<br> std::chrono::duration<br> and custom string and vector implementations.<br> These can either be supported natively by a future contribution to cxx, or by using its ExternType facilities. We have only included types in this category that we believe are relatively straightforward to implement and have a reasonable chance of being accepted into the cxx project.<br> We don't need/intend to support<br> Some types are exposed in today’s C++ APIs that are either an implicit part of the API, not an API we expect to want to use from Rust, or are language specific. Examples of types we do not intend to support include:<br> Mutexes - we expect that locking will take place in one language or the other, rather than needing to pass mutexes between languages, as per our coarse-grained philosophy.<br> native_handle<br> - this is a JNI interface type, so it is inappropriate for use in Rust/C++ communication.<br> std::locale&<br> - Android uses a separate locale system from C++ locales. This type primarily appears in output due to e.g.,<br> cout<br> usage, which would be inappropriate to use in Rust.<br> Overall, this category represents types that we do not believe a Rust developer should be using.<br> HIDL<br> Android is in the process of deprecating <a rel="noreferrer" target="_blank" href="https://source.android.com/devices/architecture/hidl">HIDL</a> and migrating to <a rel="noreferrer" target="_blank" href="https://source.android.com/devices/architecture/aidl/aidl-hals">AIDL for HALs</a> for new services.We’re also migrating some existing implementations to stable AIDL. Our current plan is to not support HIDL, preferring to migrate to stable AIDL instead. These types thus currently fall into the “We don't need/intend to support'' bucket above, but we break them out to be more specific. If there is sufficient demand for HIDL support, we may revisit this decision later.<br> Other<br> This contains all types that do not fit into any of the above buckets. It is currently mostly<br> being passed by value, which is not supported by cxx.<br> Top C++ libraries<br> One of the primary reasons for supporting interop is to allow reuse of existing code. With this in mind, we determined the most commonly used C++ libraries in Android:<br> liblog<br> libbase<br> libutils<br> libcutils<br> libhidlbase<br> libbinder<br> libhardware<br> libz<br> libcrypto<br> , and<br> libui<br> . We then analyzed all of the external C++ functions used by these libraries and their arguments to determine how well they would interoperate with Rust.<br> Overall, 81% of types are in the first three categories (which we currently fully support) and 87% are in the first four categories (which includes those we believe we can easily support). Almost all of the remaining types are those we believe we do not need to support.<br> Mainline modules<br> In addition to analyzing popular C++ libraries, we also examined <a rel="noreferrer" target="_blank" href="https://source.android.com/devices/architecture/modular-system">Mainline modules</a> . Supporting this context is critical as Android is <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2019/05/fresher-os-with-projects-treble-and-mainline.html">migrating some of its core functionality to Mainline</a> , including much of the native code we hope to augment with Rust. Additionally, their modularity presents an opportunity for interop support.<br> We analyzed 64 binaries and libraries in 21 modules. For each analyzed library we examined their used C++ functions and analyzed the types of their arguments to determine how well they would interoperate with Rust in the same way we did above for the top 10 libraries.<br> Here 88% of types are in the first three categories and 90% in the first four, with almost all of the remaining being types we do not need to handle.<br> Analysis of Rust/C++ Interop in AOSP<br> With almost a year of Rust development in AOSP behind us, and more than a hundred thousand lines of code written in Rust, we can now examine how our original analysis has held up based on how C/C++ code is currently called from Rust in AOSP. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn4">4</a><br> The results largely match what we expected from our analysis with bindgen handling the majority of interop needs. Extensive use of AIDL by the new Keystore2 service results in the primary difference between our original analysis and actual Rust usage in the “Native Support” category.<br> A few current examples of interop are:<br> <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:system/bt/gd/rust/shim/src/hci.rs;l=9;drc=1417e3ea64248efebaa432d0428fce7f6c734104">Cxx in Bluetooth</a> - While Rust is intended to be the primary language for Bluetooth, migrating from the existing C/C++ implementation will happen in stages. Using cxx allows the Bluetooth team to more easily serve legacy protocols like HIDL until they are phased out by using the existing C++ support to incrementally migrate their service.<br> <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:system/security/keystore2/src/service.rs;l=343;drc=3ed5da79ae8698ded3684577b6b5094d9d596399">AIDL in keystore</a> - … https://www.whatsupup.com/blog/ewing/undiscernibly/20210604-141506/ Fri, 04 Jun 2021 14:15:05 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210604-141506/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/announcing-new-abuse-research-grants.html">Announcing New Abuse Research Grants Program</a><br></p> <hr> Posted by Anna Hupa,  Marc Henson, and Martin Straka, Google VRP Team <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/announcing-new-abuse-research-grants.html">Read More</a><br> Posted by Anna Hupa,  Marc Henson, and Martin Straka, Google VRP Team<br> Our Abuse Bug Bounty program has proved tremendously successful in the past three years since its introduction – thanks to our incredibly engaged community of researchers. Their contributions resulted in +1,000 valid bugs, helping us raise the bar in combating <a rel="noreferrer" target="_blank" href="http://goo.gle/abuse-risk">product abuse</a> . As a result of this continued success, today we are announcing a new experimental Abuse Research Grants Program in addition to the already existing <a rel="noreferrer" target="_blank" href="https://www.blogger.com/">Vulnerability Research Grants</a> . Similar to other Research Grant Programs, these grants are up-front awards that our top researchers will receive before they ever submit a bug. Last year, we <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/09/announcing-new-reward-amounts-for-abuse.html">increased our rewards</a> to recognize the important work of our community. The growth of this program would not have been possible without partners like David ( <a rel="noreferrer" target="_blank" href="https://twitter.com/xdavidhu">@xdavidhu</a> ), Zohar ( <a rel="noreferrer" target="_blank" href="https://www.ehpus.com/">ehpus.com</a> ), and Ademar ( <a rel="noreferrer" target="_blank" href="https://twitter.com/nowaskyjr">@nowaskyjr</a> ) who, on top of becoming our top research experts in <a rel="noreferrer" target="_blank" href="http://goo.gle/abuse-risk">Product Abuse</a> , regularly contribute to transparency by sharing their work, further inspiring and influencing our community of researchers. Despite the growth and success of this program, there remains more work to be done. With our new Abuse Research Grants Program, we hope to bring even more awareness to product abuse by connecting more closely with our experienced researchers – so we can all work together to overcome these challenges, prevent product abuse and keep our users safe. Here’s how the program works:<br> We invite our top abuse researchers to the program.<br> We award grants immediately before research begins, no strings attached.<br> Bug Hunters apply for the targets we share with them and start their research.<br> On top of the grant, researchers are eligible for regular rewards for the bugs they discover in scope of <a rel="noreferrer" target="_blank" href="http://goo.gle/vrp">our Bug Bounty program</a> .<br> To learn more about this and other grant programs, visit <a rel="noreferrer" target="_blank" href="http://goo.gle/grantz">our rules page</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210603-201555/ Thu, 03 Jun 2021 20:15:54 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210603-201555/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/06/new-protections-for-enhanced-safe.html">New protections for Enhanced Safe Browsing users in Chrome</a><br></p> <hr> Posted by Badr Salmi, Google Safe Browsing & Varun Khaneja, Chrome Security<br> In 2020 we <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html">launched Enhanced Safe Browsing</a> , which you can turn on in your Chrome security <a rel="noreferrer" target="_blank" href="https://support.google.com/chrome/answer/9890866">settings</a> , with the goal of substantially increasing safety on the web. These improvements are being built on top of existing security mechanisms that already protect billions of devices. Since the initial launch, we have continuously worked behind the scenes to improve our real-time URL checks and apply machine learning models to warn on previously-unknown attacks. As a result, Enhanced Safe Browsing users are successfully phished 35% less than other users. Starting with Chrome 91, we will roll out new features to help Enhanced Safe Browsing users better choose their extensions, as well as offer additional protections against downloading malicious files on the web.<br> Chrome extensions - Better protection before installation<br> Every day millions of people rely on Chrome extensions to help them be more productive, save money, shop or simply improve their browser experience. This is why it is important for us to continuously improve the safety of extensions published in the Chrome Web Store. For instance, through our integration with Google Safe Browsing in 2020, the number of malicious extensions that Chrome disabled to protect users grew by 81%. This comes on top of a <a rel="noreferrer" target="_blank" href="https://blog.google/products/chrome/making-chrome-extensions-more-private-and-secure/">number of improvements</a> for more peace of mind when it comes to privacy and security.<br> Enhanced Safe Browsing will now offer additional protection when you install a new extension from the Chrome Web Store. A dialog will inform you if an extension you’re about to install is not a part of the list of extensions trusted by Enhanced Safe Browsing.<br> Any extensions built by a developer who follows the <a rel="noreferrer" target="_blank" href="https://developer.chrome.com/docs/webstore/program_policies/">Chrome Web Store Developer Program Policies</a> , will be considered trusted by Enhanced Safe Browsing. For new developers, it will take at least a few months of respecting these conditions to become trusted. Eventually, we strive for all developers with compliant extensions to reach this status upon meeting these criteria. Today, this represents nearly 75% of all extensions in the Chrome Web Store and we expect this number to keep growing as new developers become trusted.<br> Improved download protection<br> Enhanced Safe Browsing will now offer you even better protection against risky files.<br> When you download a file, Chrome performs a first level check with Google Safe Browsing using metadata about the downloaded file, such as the digest of the contents and the source of the file, to determine whether it’s potentially suspicious. For any downloads that Safe Browsing deems risky, but not clearly unsafe, Enhanced Safe Browsing users will be presented with a warning and the ability to send the file to be scanned for a more in depth analysis (pictured above).<br> If you choose to send the file, Chrome will upload it to Google Safe Browsing, which will scan it using its static and dynamic analysis classifiers in real time. After a short wait, if Safe Browsing determines the file is unsafe, Chrome will display a warning. As always, you can bypass the warning and open the file without scanning. Uploaded files are deleted from Safe Browsing a short time after scanning.<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210526-181308/ Wed, 26 May 2021 18:13:07 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210526-181308/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/introducing-security-by-design.html">Introducing Security By Design</a><br></p> <hr> Posted by Jon Markoff and Sean Smith, Android Security and Privacy Team <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/introducing-security-by-design.html">Read More</a><br> Posted by Jon Markoff and Sean Smith, Android Security and Privacy Team<br> Integrating security into your app development lifecycle can save a lot of time, money, and risk. That’s why we’ve launched <a rel="noreferrer" target="_blank" href="https://playacademy.exceedlms.com/student/path/63550-security-by-design">Security by Design</a> on <a rel="noreferrer" target="_blank" href="https://playacademy.exceedlms.com/student/catalog">Google Play Academy</a> to help developers identify, mitigate, and proactively protect against security threats.<br> The Android ecosystem, including Google Play, has many built-in security features that help protect developers and users. The course <a rel="noreferrer" target="_blank" href="https://g.co/playacademy/security?utm_source=google&utm_medium=blog&utm_campaign=Security&utm_content=androidblog">Introduction to app security best practices</a> takes these protections one step further by helping you take advantage of additional security features to build into your app. For example, <a rel="noreferrer" target="_blank" href="https://developer.android.com/topic/security/data">Jetpack Security</a> helps developers properly encrypt their data at rest and provides only safe and well known algorithms for encrypting Files and SharedPreferences. The <a rel="noreferrer" target="_blank" href="https://developer.android.com/training/safetynet/attestation">SafetyNet Attestation API</a> is a solution to help identify potentially dangerous patterns in usage. There are several common design vulnerabilities that are important to look out for, including using shared or improper file storage, using insecure protocols, unprotected components such as Activities, and more. The course also provides methods to test your app in order to help you keep it safe after launch. Finally, you can set up a <a rel="noreferrer" target="_blank" href="https://developers.google.com/android/play-protect/starting-a-vdp">Vulnerability Disclosure Program</a> (VDP) to engage security researchers to help.<br> In the next course, you can learn how to integrate security at every stage of the development process by adopting the <a rel="noreferrer" target="_blank" href="https://playacademy.exceedlms.com/student/activity/69287-introduction-to-the-security-development-lifecycle">Security Development Lifecycle</a> (SDL). The SDL is an industry standard process and in this course you’ll learn the fundamentals of setting up a program, getting executive sponsorship and integration into your development lifecycle.<br> Threat modeling is part of the Security Development Lifecycle, and in this course you will learn to think like an attacker to identify, categorize, and address threats. By doing so early in the design phase of development, you can identify potential threats and start planning for how to mitigate them at a much lower cost and create a more secure product for your users.<br> Improving your app’s security is a never ending process. Sign up for the Security by Design <a rel="noreferrer" target="_blank" href="https://playacademy.exceedlms.com/student/path/63550-security-by-design">module</a> where in a few short courses, you will learn how to integrate security into your app development lifecycle, model potential threats, and app security best practices into your app, as well as avoid potential design pitfalls.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android">android</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android%20security">android security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/app%20security">app security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/encryption">encryption</a><br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/encryption">encryption</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210525-161600/ Tue, 25 May 2021 16:16:00 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210525-161600/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/introducing-half-double-new-hammering.html">Introducing Half-Double: New hammering technique for DRAM Rowhammer bug</a><br></p> <hr> Research Team: Salman Qazi, Yoongu Kim, Nicolas Boichat, Eric Shiu & Mattias Nissler Today, we are sharing details around our discovery of <a rel="noreferrer" target="_blank" href="https://github.com/google/hammer-kit/blob/main/20210525_half_double.pdf">Half-Double</a> , a new Rowhammer technique that capitalizes on the worsening physics of some of the newer DRAM chips to alter the contents of memory. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/introducing-half-double-new-hammering.html">Read More</a><br> Research Team: Salman Qazi, Yoongu Kim, Nicolas Boichat, Eric Shiu & Mattias Nissler Today, we are sharing details around our discovery of <a rel="noreferrer" target="_blank" href="https://github.com/google/hammer-kit/blob/main/20210525_half_double.pdf">Half-Double</a> , a new Rowhammer technique that capitalizes on the worsening physics of some of the newer DRAM chips to alter the contents of memory. Rowhammer is a DRAM vulnerability whereby repeated accesses to one address can tamper with the data stored at other addresses. Much like speculative execution vulnerabilities in CPUs, Rowhammer is a breach of the security guarantees made by the underlying hardware. As an electrical coupling phenomenon within the silicon itself, Rowhammer allows the potential bypass of hardware and software memory protection policies. This can allow untrusted code to break out of its sandbox and take full control of the system. Rowhammer was first discussed in a <a rel="noreferrer" target="_blank" href="https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf">paper</a> in 2014 for what was then the mainstream generation of DRAM: DDR3. The following year, Google’s Project Zero released a working privilege-escalation <a rel="noreferrer" target="_blank" href="https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html">exploit</a> . In response, DRAM manufacturers implemented proprietary logic inside their chips that attempted to track frequently accessed addresses and reactively mitigate when necessary. As DDR4 became widely adopted, it appeared as though Rowhammer had faded away thanks in part to these built-in defense mechanisms. However, in 2020, the <a rel="noreferrer" target="_blank" href="https://www.vusec.net/projects/trrespass/">TRRespass</a> paper showed how to reverse-engineer and neutralize the defense by distributing accesses, demonstrating that Rowhammer techniques are still viable. Earlier this year, the <a rel="noreferrer" target="_blank" href="https://www.vusec.net/projects/smash/">SMASH</a> research went one step further and demonstrated exploitation from JavaScript, without invoking cache-management primitives or system calls. Traditionally, Rowhammer was understood to operate at a distance of one row: when a DRAM row is accessed repeatedly (the “aggressor”), bit flips were found only in the two adjacent rows (the “victims”). However, with Half-Double, we have observed Rowhammer effects propagating to rows beyond adjacent neighbors, albeit at a reduced strength. Given three consecutive rows A, B, and C, we were able to attack C by directing a very large number of accesses to A, along with just a handful (~dozens) to B. Based on our experiments, accesses to B have a non-linear gating effect, in which they appear to “transport” the Rowhammer effect of A onto C. Unlike TRRespass, which exploits the blind spots of manufacturer-dependent defenses, Half-Double is an intrinsic property of the underlying silicon substrate. This is likely an indication that the electrical coupling responsible for Rowhammer is a property of distance, effectively becoming stronger and longer-ranged as cell geometries shrink down. Distances greater than two are conceivable.<br> Google has been working with <a rel="noreferrer" target="_blank" href="https://www.jedec.org/">JEDEC</a> , an independent semiconductor engineering trade organization, along with other industry partners, in search of possible solutions for the Rowhammer phenomenon. JEDEC has published two documents about DRAM and system-level mitigation techniques (JEP <a rel="noreferrer" target="_blank" href="https://www.jedec.org/standards-documents/docs/jep300-1">300-1</a> and JEP <a rel="noreferrer" target="_blank" href="https://www.jedec.org/standards-documents/docs/jep301-1">301-1</a> ). We are disclosing this work because we believe that it significantly advances the understanding of the Rowhammer phenomenon, and that it will help both researchers and industry partners to work together, to develop lasting solutions. The challenge is substantial and the ramifications are industry-wide. We encourage all stakeholders (server, client, mobile, automotive, IoT) to join the effort to develop a practical and effective solution that benefits all of our users.<br> Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Rowhammer">Rowhammer</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Security">Security</a><br> <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/Rowhammer">Rowhammer</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210512-181441/ Wed, 12 May 2021 18:14:40 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210512-181441/ Labels: <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android">android</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/android%20security">android security</a> , <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/search/label/rust">rust</a><br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210511-181459/ Tue, 11 May 2021 18:14:57 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210511-181459/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/integrating-rust-into-android-open.html">Integrating Rust Into the Android Open Source Project</a><br></p> <hr> Posted by Ivan Lozano, Android Team<br> The Android team has been working on introducing the Rust programming language into the Android Open Source Project (AOSP) since 2019 as a memory-safe alternative for platform native code development. As with any large project, introducing a new language requires careful consideration. For Android, one important area was assessing how to best fit Rust into Android’s build system. Currently this means the <a rel="noreferrer" target="_blank" href="https://source.android.com/setup/build">Soong</a> build system (where the Rust support resides), but these design decisions and considerations are equally applicable for <a rel="noreferrer" target="_blank" href="https://blog.bazel.build/2020/11/12/aosp_migrating_to_bazel.html">Bazel</a> when AOSP migrates to that build system. This post discusses some of the key design considerations and resulting decisions we made in integrating Rust support into Android’s build system.<br> Rust integration into large projects<br> A RustConf 2019 meeting on <a rel="noreferrer" target="_blank" href="https://users.rust-lang.org/t/rust-in-large-organizations-meeting/32059">Rust usage within large organizations</a> highlighted several challenges, such as the risk that eschewing Cargo in favor of using the Rust Compiler,<br> rustc,<br> directly (see next section) may remove organizations from the wider Rust community. We share this same concern. When changes to imported third-party crates might be beneficial to the wider community, our goal is to upstream those changes. Likewise when crates developed for Android could benefit the wider Rust community, we hope to release them as independent crates. We believe that the success of Rust within Android is dependent on minimizing any divergence between Android and the Rust community at large, and hope that the Rust community will benefit from Android’s involvement.<br> No nested build systems<br> Rust provides Cargo as the default <a rel="noreferrer" target="_blank" href="https://doc.rust-lang.org/book/ch01-03-hello-cargo.html">build system and package manager</a> , collecting dependencies and invoking<br> rustc<br> (the Rust compiler) to build the target crate (Rust package). <a rel="noreferrer" target="_blank" href="https://android.googlesource.com/platform/build/soong/+/refs/heads/master/README.md">Soong</a> takes this role instead in Android and calls<br> directly for several reasons:<br> In Cargo, C dependencies are handled independently in an ad-hoc manner via build.rs scripts. Soong already provides a mechanism for building C libraries and defining them as dependencies, and Android carefully controls the compiler version and global compilation flags to ensure libraries are built a particular way. Relying on Cargo would introduce a second non-Soong mechanism for defining/building C libraries that would not be constrained by the carefully selected compilation controls implemented in Soong. This could also lead to multiple different versions of the same library, negatively impacting memory/disk usage.<br> Calling compilers directly through Soong provides the stability and control Android requires for the variety of build configurations it supports (for example, specifying where target-specific dependencies are and which compilation flags to use). While it would technically be possible to achieve the necessary level of control over<br> indirectly through Cargo, Soong would have no understanding of how the<br> Cargo.toml<br> (the Cargo build file) would influence the commands Cargo emits to<br> . Paired with the fact that Cargo evolves independently, this would severely restrict Soong’s ability to precisely control how build artifacts are created.<br> Builds which are self-contained and insensitive to the host configuration, known as hermetic builds , are necessary for Android to produce reproducible builds. Cargo, which relies on<br> build.rs<br> scripts, doesn’t yet provide hermeticity guarantees.<br> Incremental builds are important to maintain engineering productivity; building Android takes a considerable amount of resources. Cargo was not designed for integration into existing build systems and does not expose its compilation units. Each Cargo invocation builds <a rel="noreferrer" target="_blank" href="https://github.com/rust-lang/rust-roadmap-2017/issues/12#issuecomment-278118819">the entire crate dependency graph</a> for a given<br> , rebuilding crates multiple times across projects <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn1">1</a> . This is too coarse for integration into Soong’s incremental build support, which expects smaller compilation units. This support is necessary to scale up Rust usage within Android.<br> Using the Rust compiler directly allows us to avoid these issues and is consistent with how we compile all other code in AOSP. It provides the most control over the build process and eases integration into Android’s existing build system. Unfortunately, avoiding it introduces several challenges and influences many other build system decisions because Cargo usage is so deeply ingrained in the Rust crate ecosystem.<br> No build.rs scripts<br> A<br> script compiles to a Rust binary which Cargo builds and executes during a build to handle pre-build tasks, commonly setting up the build environment, or building libraries in other languages (for example C/C++). This is analogous to configure scripts used for other languages.<br> Avoiding<br> scripts somewhat flows naturally from not relying on Cargo since supporting these would require replicating Cargo behavior and assumptions. Beyond this however, there are good reasons for AOSP to avoid build scripts as well:<br> scripts can execute arbitrary code on the build host. From a security perspective, this introduces an additional burden when adding or updating third-party code as the<br> script needs careful scrutiny.<br> Third-party<br> scripts may not be hermetic or reproducible in <a rel="noreferrer" target="_blank" href="https://github.com/rust-lang/cargo/issues/9273#issuecomment-800765010">potentially subtle ways</a> . It is also common for<br> files to access files outside the build directory (such as<br> /usr/lib<br> ). When they are not hermetic, we would need to either carry a local patch or work with upstream to resolve the issue.<br> The most common task for<br> is to build C libraries which Rust code depends on. We already support this through Soong.<br> Android likewise avoids running build scripts while building for other languages, instead, simply using them to inform the structure of the<br> Android.bp<br> file.<br> For instances in third-party code where a build script is used only to compile C dependencies, we either use existing<br> cc_library<br> Soong definitions (such as <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/boringssl/Android.bp;drc=859a48db620ed6a63b786182d1bb55f04d1f124c;l=312">boringssl</a> for <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/quiche/Android.bp;drc=1b19aa5ba6b71372df6ec176d15993631552c2eb;l=65">quiche</a> ) or <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/grpcio-sys/Android.bp;drc=bb4f797895a614ac15d1ea90a62660900a6a6b30;l=68">create new definitions</a> for crate-specific code.<br> When the <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/libsqlite3-sys/build.rs;l=379;drc=cc6e6357c57e09c4078b3c54cac455111dd3e221">build.rs is used to generate source</a> , we try to replicate <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/libsqlite3-sys/android/build.rs;drc=ae93c4c77b203617f6fdf5e5e6a0e1fee02caa91">the core functionality</a> in a Soong <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/libsqlite3-sys/android/Android.bp;drc=0f6dcf73b798c60a4ff204cc4b1a98572fec3393">rust_binary</a> module for use as a <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/libsqlite3-sys/Android.bp;drc=0f6dcf73b798c60a4ff204cc4b1a98572fec3393;l=132">custom source generator</a> . In other cases where Soong can provide the information without source generation, we may carry a <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/rustversion/patches/version.diff;drc=d550abe65fea6425374f69306f0a4e74585b238c">small patch</a> that leverages this information.<br> Why proc_macro but not build.rs?<br> Why do we support<br> proc_macros<br> , which are compiler plug-ins that execute code on the host within the compiler context, but not<br> scripts?<br> While<br> code is written as one-off code to handle building a single crate,<br> define reusable functionality within the compiler which can become widely relied upon across the Rust community. As a result popular<br> are generally better maintained and more scrutinized upstream, which makes the code review process more manageable. They are also more readily sandboxed as part of the build process since they are less likely to have dependencies external to the compiler.<br> are also a language feature rather than a method for building code. These are relied upon by source code, are unavoidable for third-party dependencies, and are useful enough to define and use within our platform code. While we can avoid build.rs by leveraging our build system, the same can’t be said of proc_macros.<br> There is also precedence for compiler plugin support within the Android build system. For example see Soong’s <a rel="noreferrer" target="_blank" href="https://ci.android.com/builds/submitted/7271141/linux/latest/raw/java.html#java_plugin">java_plugin</a> modules.<br> Generated source as crates<br> Unlike C/C++ compilers,<br> only accepts a single source file representing an entry point to a binary or library. It expects that the source tree is structured such that all required source files can be automatically discovered. This means that generated source either needs to be placed in the source tree or provided through an include directive in source:<br> include!("/path/to/hello.rs");<br> The Rust community depends on<br> scripts alongside assumptions about the Cargo build environment to <a rel="noreferrer" target="_blank" href="https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation">get around this limitation</a> . When building, the<br> cargo<br> command sets an <a rel="noreferrer" target="_blank" href="https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates">OUT_DIR environment variable</a> which build.rs scripts are expected to place generated source code in. This source can then be included via:<br> include!(concat!(env!("OUT_DIR"), "/hello.rs"));<br> This presents a challenge for Soong as outputs for each module are placed in their own<br> out/<br> directory <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn2">2</a> ; there is no single<br> OUT_DIR<br> where dependencies output their generated source.<br> For platform code, we prefer to package generated source into a crate that can be imported. There are a few reasons to favor this approach:<br> Prevent generated source file names from colliding.<br> Reduce <a rel="noreferrer" target="_blank" href="https://github.com/rust-lang/rust-bindgen/blob/master/book/src/tutorial-4.md">boilerplate code</a> checked-in throughout the tree and which needs to be maintained. Any boilerplate necessary to make the <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:build/soong/rust/protobuf.go;drc=6eff900b67a0ed7e639ae304b1d453b620e9b79d;l=174">generated source compile</a> into a crate can be centrally maintained.<br> Avoid implicit <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn3">3</a> interactions between generated code and the surrounding crate.<br> Reduce pressure on memory and disk by dynamically liking commonly used generated sources.<br> As a result, all of Android’s Rust source generation module types produce code that can be compiled and used <a rel="noreferrer" target="_blank" href="https://cs.android.com/android/platform/superproject/+/master:system/bt/gd/rust/facade/Android.bp;drc=92fa0f9ac23d547cfa62ddbf9e92e7755e1b1df6;l=19">as a crate</a> .<br> We still support third-party crates without modification by copying all the generated source dependencies for a module into a single per-module directory similar to Cargo. Soong then sets the<br> environment variable to that directory when compiling the module so the generated source can be found. However we discourage use of this mechanism in platform code unless absolutely necessary for the reasons described above.<br> Dynamic linkage by default<br> By default, the Rust ecosystem assumes that crates will be <a rel="noreferrer" target="_blank" href="https://github.com/rust-lang/rust/issues/10209">statically linked into binaries</a> . The usual benefits of dynamic libraries are upgrades (whether for security or functionality) and decreased memory usage. Rust’s lack of a stable binary interface and usage of cross-crate information flow prevents upgrading libraries without upgrading all dependent code. Even when the same crate is used by two different programs on the system, it is unlikely to be provided by the same shared object <a rel="noreferrer" target="_blank" href="https://security.googleblog.com#fn4">4</a> due to the precision with which Rust identifies its crates. This makes Rust binaries more portable but also results in … https://www.whatsupup.com/blog/ewing/undiscernibly/20210506-161427/ Thu, 06 May 2021 16:14:25 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210506-161427/ Posted by Priya Wadhwa, Jake Sanders, Google Open Source Security Team <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/making-internet-more-secure-one-signed.html">Read More</a><br> Posted by Priya Wadhwa, Jake Sanders, Google Open Source Security Team<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210506-141419/ Thu, 06 May 2021 14:14:18 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210506-141419/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/making-internet-more-secure-one-signed.html">Making the Internet more secure one signed container at a time</a><br></p> <hr> Posted by Priya Wadhwa, Google Open Source Security Team With over 16 million pulls per month, Google’s <a rel="noreferrer" target="_blank" href="https://github.com/GoogleContainerTools/distroless">`distroless` base images</a> are widely used and depended on by large projects like Kubernetes and Istio. These minimal images don’t include common tools like shells or package managers, making their attack surface (and download size!) smaller than traditional base images such as `ubuntu` or `alpine`. Even with this additional protection, users could still fall prey to typosquatting attacks, or receive a malicious image if the distroless build process was compromised – making users vulnerable to accidentally using a malicious image instead of the actual distroless image. This problem isn’t unique to distroless images – until now, there just hasn’t been an easy way to verify that images are what they claim to be. <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/making-internet-more-secure-one-signed.html">Read More</a><br> Posted by Priya Wadhwa, Google Open Source Security Team<br> With over 16 million pulls per month, Google’s <a rel="noreferrer" target="_blank" href="https://github.com/GoogleContainerTools/distroless">`distroless` base images</a> are widely used and depended on by large projects like Kubernetes and Istio. These minimal images don’t include common tools like shells or package managers, making their attack surface (and download size!) smaller than traditional base images such as `ubuntu` or `alpine`. Even with this additional protection, users could still fall prey to typosquatting attacks, or receive a malicious image if the distroless build process was compromised – making users vulnerable to accidentally using a malicious image instead of the actual distroless image. This problem isn’t unique to distroless images – until now, there just hasn’t been an easy way to verify that images are what they claim to be. Introducing Cosign <a rel="noreferrer" target="_blank" href="https://github.com/sigstore/cosign">Cosign</a> simplifies signing and verifying container images, aiming to make signatures invisible infrastructure – basically, it takes over the hard part of signing and verifying software for you. We developed cosign in collaboration with the <a rel="noreferrer" target="_blank" href="http://sigstore.dev/">sigstore project</a> , a Linux Foundation project and a non-profit service that seeks to improve the open source software supply chain by easing the adoption of cryptographic software signing, backed by transparency log technologies. We’re excited to announce that all of our distroless images are now signed by cosign! This means that all users of distroless can verify that they are indeed using the base image they intended to before kicking off image builds, making distroless images even more trustworthy. In fact, Kubernetes has already begun <a rel="noreferrer" target="_blank" href="https://github.com/kubernetes/release/pull/2016">performing this check</a> in their builds. As we look to the future, Kubernetes SIG Release's vision is to establish a consumable, introspectable, and secure supply chain for the project. By collaborating with the sigstore maintainers (who are fellow Kubernetes contributors) to integrate signing and transparency into our supply chain, we hope to be an exemplar for standards in the cloud native (and wider) tech industry, said Stephen Augustus, co-chair for Kubernetes SIG Release. How it works<br> To start signing distroless we integrated cosign into the distroless CI system, which builds and pushes images via Cloud Build. Signing every distroless image was as easy as adding an additional <a rel="noreferrer" target="_blank" href="https://github.com/GoogleContainerTools/distroless/blob/master/cloudbuild.yaml#L37">Cloud Build step</a> to the Cloud Build job responsible for building and pushing the images. This additional step uses the cosign container image and a key pair stored in <a rel="noreferrer" target="_blank" href="https://cloud.google.com/security-key-management">GCP KMS</a> to sign every distroless image. With this additional signing step, users can now verify that the distroless image they’re running was built in the correct CI environment. Right now, cosign can be run as an image or as a CLI tool. It supports:<br> Hardware and KMS signing<br> Bring-your-own PKI<br> Our free OIDC PKI (Fulcio)<br> Built-in binary transparency and timestamping service (Rekor)<br> Signing distroless with cosign is just the beginning, and we plan to incorporate other sigstore technologies into distroless to continue to improve it over the next few months. We also can’t wait to integrate sigstore with other critical projects. Stay tuned here for updates! To get started verifying your own distrolesss images, check out the distroless <a rel="noreferrer" target="_blank" href="https://github.com/GoogleContainerTools/distroless#how-do-i-verify-distroless-images">README</a> and to learn more about sigstore, check out <a rel="noreferrer" target="_blank" href="https://sigstore.dev/">sigstore.dev</a> .<br> https://www.whatsupup.com/blog/ewing/undiscernibly/20210504-181435/ Tue, 04 May 2021 18:14:34 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210504-181435/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/05/enabling-hardware-enforced-stack.html">Enabling Hardware-enforced Stack Protection (cetcompat) in Chrome</a><br></p> <hr> Alex Gough, Engineer, Chrome Platform Security Team<br> Chrome 90 for Windows adopts Hardware-enforced Stack Protection, a mitigation technology to make the exploitation of security bugs more difficult for attackers. This is supported by Windows 20H1 (December Update) or later, running on processors with Control-flow Enforcement Technology (CET) such as Intel 11th Gen or AMD Zen 3 CPUs. With this mitigation the processor maintains a new, protected, stack of valid return addresses (a shadow stack). This improves security by making exploits more difficult to write. However, it may affect stability if software that loads itself into Chrome is not compatible with the mitigation. Below we describe some exploitation techniques that are mitigated by stack protection, discuss its limitations and what we will do next to approach them. Finally, we provide some quick tips for other software authors as they enable /cetcompat for their Windows applications.<br> Stack Protection<br> Imagine a simple use-after-free (UAF) bug where an attacker can induce a program to call a pointer of their choosing. Here the attacker controls an object which occupies space formerly used by another object, which the program erroneously continues to use. The attacker sets a field in this region that is used as a function call to the address of code the attacker would like to execute. Years ago an attacker could simply write their shellcode to a known location, then, in their overwrite, set the instruction pointer to this shellcode. In time, Data Execution Prevention was added to prevent stacks or heaps from being executable.<br> In response, attackers invented Return Oriented Programming (ROP). Here, attackers take advantage of the process’s own code, as that must be executable. With control of the stack (either to write values there, or by changing the stack pointer) and control of the instruction pointer, an attacker can use the `ret` instruction to jump to a different, useful, piece of code.<br> During an exploit attempt, the instruction pointer is changed so that instead of its normal destination, a small fragment of code, called an ROP gadget, is invoked instead. These gadgets are selected so that they do something useful (such as prepare a register for a function call) then call return.<br> These tiny fragments need not be a complete function in the normal program, and could even be found part-way through a legitimate instruction. By lining up the right set of “return” addresses, a chain of these gadgets can be called, with each gadget’s `ret` switching to the next gadget. With some patience, or the right tooling, an attacker can piece together the arguments to a function call, then really call the function.<br> Chrome has a <a rel="noreferrer" target="_blank" href="https://www.google.com/googlebooks/chrome/small_04.html">multi-process architecture</a> -- a main browser process acts as the logged-in user, and spawns restricted renderer and utility processes to host website code. This isolation reduces the severity of a bug in a renderer as its process cannot do much by itself. Attackers will then attempt to use another sandbox escape bug to run code in the browser, which lets them act as the logged-in user. As libraries are mapped at the same address in different processes by Windows, any bug that allows an attacker to read memory is enough for them to examine Chrome’s binary and any loaded libraries for ROP gadgets. This makes preventing ROP chains in the browser process especially useful as a mitigation.<br> Enter stack-protection. Along with the existing stack, the cpu maintains a shadow stack. This stack cannot be directly manipulated by normal program code and only stores return addresses. The CALL instruction is modified to push a return address (the instruction after the CALL) to both the normal stack, and the shadow stack. The RET (return) instruction still takes its return address from the normal stack, but now verifies that it is the same as the one stored in the shadow stack region. If it is, then the program is left alone and it continues to work as it always did. If the addresses do not match then an exception is raised which is intercepted by the operating system (not by Chrome). The operating system has an opportunity to modify the shadow region and allow the program to continue, but in most cases an address mismatch is the result of a program error so the program is immediately terminated.<br> In our example above, the attacker will be able to make their initial jump into a ROP gadget, but on trying to return to their next gadget they will be stopped.<br> Some software may be incompatible with this mechanism, especially some older security software that injects into a process and hooks operating system functions by overwriting the prelude with `rax = &hook; push rax; ret`.<br> Limitations<br> Chrome does not yet support every direction of control flow enforcement. Stack protection enforces the reverse-edge of the call graph but does not constrain the forward-edge. It will still be possible to make indirect jumps around existing code as stack protection is only validated when a return instruction is encountered, and call targets are not validated. On Windows a technology called Control Flow Guard (CFG) can be used to verify the target of an indirect function call before it is attempted. This prevents calling into the middle of a function, significantly reducing the scope of useful instructions for attackers to use. Another approach is provided by Intel’s CET which includes an ENDBRANCH instruction to prevent jumps into arbitrary code locations. Memory tagging tools such as MTE can be used to make it more difficult to modify pointers to valid code sequences (and makes UAFs more difficult in general). We are <a rel="noreferrer" target="_blank" href="https://bugs.chromium.org/p/chromium/issues/detail?id=584575">working to introduce CFG</a> to Chrome for Windows, and will add other techniques over time.<br> By itself, stack protection can be bypassed in some contexts. For instance, stack protection does not prevent an attacker tricking a program into calling an existing function by entirely replacing an object containing a function pointer. This approach does not involve ROP as the function call happens instead of the expected call, and returns to the address it was originally called from, so must be allowed. However, the called function must be useful to an attacker, and most functions will not be. An example of an attack using this method is to craft a call to add the `--no-sandbox` argument to Chrome’s command line. This results in future renderers being launched without normal protections. Over time we will identify and <a rel="noreferrer" target="_blank" href="https://crbug.com/1195976">remove</a> such useful tools.<br> In the renderer, for performance reasons, our javascript and wasm engines may use memory that is both writable and executable at the same time. This allows an attacker to modify code that v8 is already going to execute, saving them the trouble of constructing a ROP chain. This explains why it was not our first priority to make v8 CET compatible, and why stack-protection is not yet enabled in the renderer.<br> Finally, stack protection doesn’t stop the bugs in the first place. Everything we have discussed above is a mitigation that makes it more difficult to execute arbitrary code. If a programming error allows arbitrary writes then it is very unlikely that we can prevent this being used to run arbitrary code. Attackers will adapt and find new ways to turn memory safety errors into code execution.<br> Debugging Tips<br> You can see if Hardware-enforced Stack Protection is enabled for a process using the Windows Task Manager. Open task manager, open the Details Tab, Right Click on a heading, Select Columns & Check the Hardware-enforced Stack Protection box. The process display will then indicate if a process is opted-in to this mitigation. ‘Compatible Modules Only’ indicates that any dll marked as /cetcompat at build time will raise an exception if a return address is invalid.<br> You can see which Chrome processes are opted-out of CET by consulting the Mitigations field of chrome://sandbox and clicking ‘+’. All processes are included unless the mitigation CET_USER_SHADOW_STACKS_ALWAYS_OFF is present in the expanded details view.<br> If you are developing software, or debugging a problem in Chrome the shadow stack can be helpful as it includes only return addresses, and these cannot be corrupted by rogue writes elsewhere in the process. To see these registers use the `r` command in windbg with the mask option:<br> 0:159> rM 8002<br> rax=00000000c000060a rbx=000000fa5bbfeff0 rcx=0000000000000030<br> rdx=0000000000000000 rsi=00007ffba4118924 rdi=000000fa5bbff1a0<br> rip=00007ffc1847b4a1 rsp=000000fa5bbfc0a0 rbp=000000fa5bbfc0a0<br> r8=000000fa5bbfc098 r9=0000000000000000 r10=0000000000000000<br> r11=0000000000000246 r12=000000fa5bbfe230 r13=000002c3450b5830<br> r14=000002c3450b7850 r15=000000fa5bbfc260<br> iopl=0 nv up ei pl zr na po nc<br> ssp=000000fa5c3fef10 cetumsr=0000000000000001<br> `ssp` points to the shadow stack region, `cetumsr` indicates if cet is enabled for the process.<br> You can then see the call stack within the shadow region using `dps @ssp`. Values are not overwritten so you can also see where you came from by looking a bit deeper: `dps @ssp-20`.<br> If a process is not compatible with Hardware-enforced Stack Protection, the system event log (Application Log) will include brief error reports (Id:1001). You can filter those related to cetcompat using the following powershell snippet:-<br> Get-WinEvent -MaxEvents 128 -FilterHashtable @{ LogName='Application'; Id='1001' } `<br> | Where-Object {$_.Message -match 'chrome.exe'} `<br> | Select-Object -First 8 `<br> | fl<br> These will include the following parameters:-<br> P1: application.exe<br> P2: application version<br> P3: application build ts<br> P4: faulting module .dll<br> P5: faulting module version<br> P6: faulting module build ts<br> P7: faulting offset in P4 from base_address<br> P8: exception code (c0000409)<br> P9: subcode (00...000030)<br> If Chrome is misbehaving and you think it might be because of cetcompat, it is possible to disable it using Image File Execution Options - we … https://www.whatsupup.com/blog/laureling/largish/000000-000000/ Fri, 30 Apr 2021 04:13:27 +0000 https://www.whatsupup.com/blog/laureling/largish/000000-000000/ [Marking site as being monitored from now on] https://www.whatsupup.com/blog/ewing/undiscernibly/20210422-004049/ Thu, 22 Apr 2021 00:40:48 +0000 https://www.whatsupup.com/blog/ewing/undiscernibly/20210422-004049/ <p><a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/04/how-we-fought-bad-apps-and-developers.html">How we fought bad apps and developers in 2020</a><br></p> <hr> Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play <a rel="noreferrer" target="_blank" href="https://security.googleblog.com/2021/04/how-we-fought-bad-apps-and-developers.html">Read More</a><br> Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play<br> Providing safe experiences to billions of users and millions of Android developers has been one of the highest priorities for Google Play for many years. Last year we introduced new policies, improved our systems, and further optimized our processes to better protect our users, assist good developers and strengthen our guard against bad apps and developers. Additionally, in 2020, Google Play Protect scanned over 100B installed apps each day for malware across billions of devices.<br> Users come to Google Play to find helpful, reliable apps on everything from COVID-19 vaccine information to new forms of entertainment, grocery delivery, communication and more.<br> As such, we introduced a series of policies and new developer support to continue to elevate information quality on the platform and reduce the risk of user harm from misinformation.<br> COVID-19 apps requirements: To ensure public safety, information integrity and privacy, we introduced <a rel="noreferrer" target="_blank" href="https://support.google.com/googleplay/android-developer/answer/9889712?hl=en#zippy=%2Cofficial-governmental-apps-eligible-for-covid--resource-portions-of-the-google-play-store">specific requirements</a> for COVID-19 apps. Under these requirements, apps related to sensitive use cases, such as those providing testing information, must be endorsed by either official governmental entities or healthcare organizations and must meet a high standard for user data privacy.<br> News policy: To promote transparency in news publishing, we <a rel="noreferrer" target="_blank" href="https://blog.google/outreach-initiatives/civics/google-play-helping-safeguard-elections/">introduced</a> minimum requirements that apps must meet in order for developers to declare their app as a “News” app on Google Play. These <a rel="noreferrer" target="_blank" href="https://support.google.com/googleplay/android-developer/answer/9935326">guidelines</a> help promote user transparency and developer accountability by providing users with relevant information about the app.<br> Election support: We created <a rel="noreferrer" target="_blank" href="https://blog.google/outreach-initiatives/civics/google-play-helping-safeguard-elections/">teams</a> and processes across Google Play focused on elections to provide additional support and adapt to the changing landscape. This includes support for government agencies, specially trained app reviewers, and a safety team to address election threats and abuse.<br> Our core efforts around identifying and mitigating bad apps and developers continued to evolve to address new adversarial behaviors and forms of abuse. Our machine-learning detection capabilities and enhanced app review processes prevented over 962k policy-violating app submissions from getting published to Google Play. We also banned 119k malicious and spammy developer accounts. Additionally, we significantly increased our focus on SDK enforcement, as we've found these violations have an outsized impact on security and user data privacy.<br> Last year, we continued to reduce developer access to sensitive permissions. In February, we <a rel="noreferrer" target="_blank" href="https://android-developers.googleblog.com/2020/02/safer-location-access.html">announced</a> a new background location policy to ensure that apps requesting this permission need the data in order to provide clear user benefit. As a result of the new policy, developers now have to demonstrate that benefit and prominently tell users about it or face possible removal from Google Play. We've begun enforcement on apps not meeting new policy guidelines and will provide an update on the usage of this permission in a future blog post.<br> We've also continued to invest in protecting kids and helping parents find great content. In 2020 we <a rel="noreferrer" target="_blank" href="https://blog.google/products/google-play/teacher-approved-apps/">launched</a> a new kids tab filled with “Teacher approved” apps. To evaluate apps, we teamed with academic experts and teachers across the country, including our lead advisors, Joe Blatt (Harvard Graduate School of Education) and Dr. Sandra Calvert (Georgetown University).<br> As we continue to invest in protecting people from apps with harmful content, malicious behaviors, or threats to user privacy, we are also equally motivated to <a rel="noreferrer" target="_blank" href="https://playacademy.exceedlms.com/student/activity/39632-what-s-new-in-google-play-policy-july-2020">provide trusted experiences to Play developers</a> . For example, we’ve improved our process for providing relevant information about enforcement actions we’ve taken, resulting in significant reduction in appeals and increased developer satisfaction. We will continue to enhance the speed and quality of our communications to developers, and continue listening to feedback about how we can further engage and elevate trusted developers. Android developers can expect to see more on this front in the coming year.<br> Our global teams of product managers, engineers, policy experts, and operations leaders are more excited than ever to advance the safety of the platform and forge a sustaining trust with our users. We look forward to building an even better Google Play experience.<br>