What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2024-04-18 13:40:42 | Empêcher les fuites de données généatives de l'IA avec Chrome Enterprise DLP Prevent Generative AI Data Leaks with Chrome Enterprise DLP (lien direct) |
Publié Kaleigh Rosenblat, Chrome Enterprise Senior Staff Engineer, Security Lead L'IA générative est devenue un outil puissant et populaire pour automatiser la création de contenu et des tâches simples.De la création de contenu personnalisée à la génération de code source, il peut augmenter à la fois notre productivité et notre potentiel créatif. Les entreprises souhaitent tirer parti de la puissance des LLM, comme les Gémeaux, mais beaucoup peuvent avoir des problèmes de sécurité et souhaiter plus de contrôle sur la façon dont les employés s'assurent de ces nouveaux outils.Par exemple, les entreprises peuvent vouloir s'assurer que diverses formes de données sensibles, telles que des informations personnellement identifiables (PII), des dossiers financiers et de la propriété intellectuelle interne, ne doit pas être partagé publiquement sur les plateformes d'IA génératrices.Les dirigeants de la sécurité sont confrontés au défi de trouver le bon équilibre - permettant aux employés de tirer parti de l'IA pour augmenter l'efficacité, tout en protégeant les données des entreprises. Dans cet article de blog, nous explorerons des politiques de reportage et d'application que les équipes de sécurité des entreprises peuvent mettre en œuvre dans Chrome Enterprise Premium Pour la prévention des pertes de données (DLP). 1. & nbsp; Voir les événements de connexion * pour comprendre l'utilisation des services d'IA génératifs au sein de l'organisation.Avec Chrome Enterprise \'s Reporting Connector , la sécurité et les équipes informatiques peuvent voir quand unL'utilisateur se connecte avec succès dans un domaine spécifique, y compris les sites Web d'IA génératifs.Les équipes d'opérations de sécurité peuvent tirer parti de cette télémétrie pour détecter les anomalies et les menaces en diffusant les données dans chronique ou autre tiers siems sans frais supplémentaires. 2. & nbsp; Activer le filtrage URL pour avertir les utilisateurs des politiques de données sensibles et les laisser décider s'ils souhaitent ou non accéder à l'URL, ou pour empêcher les utilisateurs de passer à certains groupes de sites. Par exemple, avec le filtrage d'URL de l'entreprise Chrome, les administrateurs informatiques peuvent créer des règlesqui avertissent les développeurs de ne pas soumettre le code source à des applications ou outils AI génératifs spécifiques, ou de les bloquer. 3. & nbsp; avertir, bloquer ou surveiller les actions de données sensibles dans les sites Web d'IA génératifs avec des règles dynamiques basées sur le contenu pour des actions telles que la pâte, les téléchargements / téléchargements de fichiers et l'impression. & nbsp; Chrome Enterprise DLP DLPRègles Donnez aux administrateurs des administrateurs des activités granulaires sur les activités du navigateur, telles que la saisie des informations financières dans les sites Web de Gen AI.Les administrateurs peuvent personnaliser les règles du DLP pour restre | Tool Legislation | ★★★ | |
|
2024-04-08 14:12:48 | Comment nous avons construit le nouveau réseau de recherche avec la sécurité des utilisateurs et la confidentialité How we built the new Find My Device network with user security and privacy in mind (lien direct) |
Posted by Dave Kleidermacher, VP Engineering, Android Security and Privacy
Keeping people safe and their data secure and private is a top priority for Android. That is why we took our time when designing the new Find My Device, which uses a crowdsourced device-locating network to help you find your lost or misplaced devices and belongings quickly – even when they\'re offline. We gave careful consideration to the potential user security and privacy challenges that come with device finding services. During development, it was important for us to ensure the new Find My Device was secure by default and private by design. To build a private, crowdsourced device-locating network, we first conducted user research and gathered feedback from privacy and advocacy groups. Next, we developed multi-layered protections across three main areas: data safeguards, safety-first protections, and user controls. This approach provides defense-in-depth for Find My Device users.
How location crowdsourcing works on the Find My Device network
The Find My Device network locates devices by harnessing the Bluetooth proximity of surrounding Android devices. Imagine you drop your keys at a cafe. The keys themselves have no location capabilities, but they may have a Bluetooth tag attached. Nearby Android devices participating in the Find My Device network report the location of the Bluetooth tag. When the owner realizes they have lost their keys and logs into the Find My Device mobile app, they will be able to see the aggregated location contributed by nearby Android devices and locate their keys.
Find My Device network protections
Let\'s dive into key details of the multi-layered protections for the Find My Device network:
Data Safeguards: We\'ve implemented protections that help ensure the privacy of everyone participating in the network and the crowdsourced location data that powers it.
Location data is end-to-end encrypted. When Android devices participating in the network report the location of a Bluetooth tag, the location is end-to-end encrypted using a key that is only a |
Vulnerability Threat Mobile | ★★ | |
|
2024-03-28 18:16:18 | Adressez désinfectant pour le firmware à métal nu Address Sanitizer for Bare-metal Firmware (lien direct) |
Posted by Eugene Rodionov and Ivan Lozano, Android Team With steady improvements to Android userspace and kernel security, we have noticed an increasing interest from security researchers directed towards lower level firmware. This area has traditionally received less scrutiny, but is critical to device security. We have previously discussed how we have been prioritizing firmware security, and how to apply mitigations in a firmware environment to mitigate unknown vulnerabilities. In this post we will show how the Kernel Address Sanitizer (KASan) can be used to proactively discover vulnerabilities earlier in the development lifecycle. Despite the narrow application implied by its name, KASan is applicable to a wide-range of firmware targets. Using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices. We\'ve already used KASan in some firmware targets to proactively find and fix 40+ memory safety bugs and vulnerabilities, including some of critical severity. Along with this blog post we are releasing a small project which demonstrates an implementation of KASan for bare-metal targets leveraging the QEMU system emulator. Readers can refer to this implementation for technical details while following the blog post. Address Sanitizer (ASan) overview Address sanitizer is a compiler-based instrumentation tool used to identify invalid memory access operations during runtime. It is capable of detecting the following classes of temporal and spatial memory safety bugs: out-of-bounds memory access use-after-free double/invalid free use-after-return ASan relies on the compiler to instrument code with dynamic checks for virtual addresses used in load/store operations. A separate runtime library defines the instrumentation hooks for the heap memory and error reporting. For most user-space targets (such as aarch64-linux-android) ASan can be enabled as simply as using the -fsanitize=address compiler option for Clang due to existing support of this target both in the toolchain and in the libclang_rt runtime. However, the situation is rather different for bare-metal code which is frequently built with the none system targets, such as arm-none-eabi. Unlike traditional user-space programs, bare-metal code running inside an embedded system often doesn\'t have a common runtime implementation. As such, LLVM can\'t provide a default runtime for these environments. To provide custom implementations for the necessary runtime routines, the Clang toolchain exposes an interface for address sanitization through the -fsanitize=kernel-address compiler option. The KASan runtime routines implemented in the Linux kernel serve as a great example of how to define a KASan runtime for targets which aren\'t supported by default with -fsanitize=address. We\'ll demonstrate how to use the version of address sanitizer originally built for the kernel on other bare-metal targets. KASan 101 Let\'s take a look at the KASan major building blocks from a high-level perspective (a thorough explanation of how ASan works under-the-hood is provided in this whitepaper). The main idea behind KASan is that every memory access operation, such as load/store instructions and memory copy functions (for example, memm | Tool Vulnerability Mobile Technical | ★★ | |
|
2024-03-28 14:29:57 | Approche de Google Public DNS \\ pour lutter contre les attaques d'empoisonnement au cache Google Public DNS\\'s approach to fight against cache poisoning attacks (lien direct) |
Tianhao Chi and Puneet Sood, Google Public DNSThe Domain Name System (DNS) is a fundamental protocol used on the Internet to translate human-readable domain names (e.g., www.example.com) into numeric IP addresses (e.g., 192.0.2.1) so that devices and servers can find and communicate with each other. When a user enters a domain name in their browser, the DNS resolver (e.g. Google Public DNS) locates the authoritative DNS nameservers for the requested name, and queries one or more of them to obtain the IP address(es) to return to the browser.When DNS was launched in the early 1980s as a trusted, content-neutral infrastructure, security was not yet a pressing concern, however, as the Internet grew DNS became vulnerable to various attacks. In this post, we will look at DNS cache poisoning attacks and how Google Public DNS addresses the risks associated with them.DNS Cache Poisoning AttacksDNS lookups in most applications are forwarded to a caching resolver (which could be local or an open resolver like. Google Public DNS). The path from a client to the resolver is usually on a local network or can be protected using encrypted transports like DoH, DoT. The resolver queries authoritative DNS servers to obtain answers for user queries. This communication primarily occurs over UDP, an insecure connectionless protocol, in which messages can be easily spoofed including the source IP address. The content of DNS queries may be sufficiently predictable that even an off-path attacker can, with enough effort, forge responses that appear to be from the queried authoritative server. This response will be cached if it matches the necessary fields and arrives before the authentic response. This type of attack is called a cache poisoning attack, which can cause great harm once successful. According to RFC 5452, the probability of success is very high without protection. Forged DNS responses can lead to denial of service, or may even compromise application security. For an excellent introduction to cache poisoning attacks, please see “ | Technical | ★★ | |
|
2024-03-14 12:01:32 | Protection d'URL en temps réel et préservant la confidentialité Real-time, privacy-preserving URL protection (lien direct) |
Posted by Jasika Bawa, Xinghui Lu, Google Chrome Security & Jonathan Li, Alex Wozniak, Google Safe Browsing
For more than 15 years, Google Safe Browsing has been protecting users from phishing, malware, unwanted software and more, by identifying and warning users about potentially abusive sites on more than 5 billion devices around the world. As attackers grow more sophisticated, we\'ve seen the need for protections that can adapt as quickly as the threats they defend against. That\'s why we\'re excited to announce a new version of Safe Browsing that will provide real-time, privacy-preserving URL protection for people using the Standard protection mode of Safe Browsing in Chrome.
Current landscape
Chrome automatically protects you by flagging potentially dangerous sites and files, hand in hand with Safe Browsing which discovers thousands of unsafe sites every day and adds them to its lists of harmful sites and files.
So far, for privacy and performance reasons, Chrome has first checked sites you visit against a locally-stored list of known unsafe sites which is updated every 30 to 60 minutes – this is done using hash-based checks.
Hash-based check overview
But unsafe sites have adapted - today, the majority of them exist for less than 10 minutes, meaning that by the time the locally-stored list of known unsafe sites is updated, many have slipped through and had the chance to do damage if users happened to visit them during this window of opportunity. Further, Safe Browsing\'s list of harmful websites continues to grow at a rapid pace. Not all devices have the resources necessary to maintain this growing list, nor are they always able to receive and apply updates to the list at the frequency necessary to benefit from full protection.
Safe Browsing\'s Enhanced protection mode already stays ahead of such threats with technologies such as real-time list checks and AI-based classification of malicious URLs and web pages. We built this mode as an opt-in to give users the choice of sharing more security-related data in order to get stronger security. This mode has shown that checking lists in real time brings significant value, so we decided to bring that to the default Standard protection mode through a new API – one that doesn\'t share the URLs of sites you visit with Google.
Introducing real-time, privacy-preserving Safe Browsing
How it works
In order to transition to real-time protection, checks now need to be performed against a list that is maintained on the Safe Browsing server. The server-side list can include unsafe sites as soon as they are discovered, so it is able to capture sites that switch quickly. It can also grow as large as needed because the |
Malware Mobile Cloud | ★★ | |
|
2024-03-12 11:59:14 | Programme de récompense de vulnérabilité: 2023 Année en revue Vulnerability Reward Program: 2023 Year in Review (lien direct) |
Posted by Sarah Jacobus, Vulnerability Rewards Team
Last year, we again witnessed the power of community-driven security efforts as researchers from around the world contributed to help us identify and address thousands of vulnerabilities in our products and services. Working with our dedicated bug hunter community, we awarded $10 million to our 600+ researchers based in 68 countries.
New Resources and Improvements
Just like every year, 2023 brought a series of changes and improvements to our vulnerability reward programs:
Through our new Bonus Awards program, we now periodically offer time-limited, extra rewards for reports to specific VRP targets.
We expanded our exploit reward program to Chrome and Cloud through the launch of v8CTF, a CTF focused on V8, the JavaScript engine that powers Chrome.
We launched Mobile VRP which focuses on first-party Android applications.
Our new Bughunters blog shared ways in which we make the internet, as a whole, safer, and what that journey entails. Take a look at our ever-growing repository of posts!
To further our engagement with top security researchers, we also hosted our yearly security conference ESCAL8 in Tokyo. It included live hacking events and competitions, student training with our init.g workshops, and talks from researchers and Googlers. Stay tuned for details on ESCAL8 2024.
As in past years, we are sharing our 2023 Year in Review statistics across all of our programs. We would like to give a special thank you to all of our dedicated researchers for their continued work with our programs - we look forward to more collaboration in the future!
Android and Google Devices
In 2023, the Android VRP achieved significant milestones, reflecting our dedication to securing the Android ecosystem. We awarded over $3.4 million in rewards to researchers who uncovered remarkable vulnerabilities within Android |
Vulnerability Threat Mobile Cloud Conference | ★★★ | |
|
2024-03-04 14:00:38 | Sécurisé par conception: la perspective de Google \\ sur la sécurité de la mémoire Secure by Design: Google\\'s Perspective on Memory Safety (lien direct) |
Alex Rebert, Software Engineer, Christoph Kern, Principal Engineer, Security FoundationsGoogle\'s Project Zero reports that memory safety vulnerabilities-security defects caused by subtle coding errors related to how a program accesses memory-have been "the standard for attacking software for the last few decades and it\'s still how attackers are having success". Their analysis shows two thirds of 0-day exploits detected in the wild used memory corruption vulnerabilities. Despite substantial investments to improve memory-unsafe languages, those vulnerabilities continue to top the most commonly exploited vulnerability classes.In this post, we share our perspective on memory safety in a comprehensive whitepaper. This paper delves into the data, challenges of tackling memory unsafety, and discusses possible approaches for achieving memory safety and their tradeoffs. We\'ll also highlight our commitments towards implementing several of the solutions outlined in the whitepaper, most recently with a $1,000,000 grant to the Rust Foundation, thereby advancing the development of a robust memory-safe ecosystem.Why we\'re publishing this now2022 marked the 50th anniversary of memory safety vulnerabilities. Since then, memo | Vulnerability Mobile | ★★ | |
|
2024-02-13 20:14:39 | Piloter de nouvelles façons de protéger les utilisateurs d'Android contre la fraude financière Piloting new ways of protecting Android users from financial fraud (lien direct) |
Posted by Eugene Liderman, Director of Mobile Security Strategy, Google From its founding, Android has been guided by principles of openness, transparency, safety, and choice. Android gives you the freedom to choose which device best fits your needs, while also providing the flexibility to download apps from a variety of sources, including preloaded app stores such as the Google Play Store or the Galaxy Store; third-party app stores; and direct downloads from the Internet.Keeping users safe in an open ecosystem takes sophisticated defenses. That\'s why Android provides multiple layers of protections, powered by AI and backed by a large dedicated security & privacy team, to help to protect our users from security threats while continually making the platform more resilient. We also provide our users with numerous built-in protections like Google Play Protect, the world\'s most widely deployed threat detection service, which actively scans over 125 billion apps on devices every day to monitor for harmful behavior. That said, our data shows that a disproportionate amount of bad actors take advantage of select APIs and distribution channels in this open ecosystem. Elevating app security in an open ecosystem While users have the flexibility to download apps from many sources, the safety of an app can vary depending on the download source. Google Play, for example, carries out rigorous operational reviews to ensure app safety, including proper high-risk API use and permissions handling. Other app stores may also follow established policies and procedures that help reduce risks to users and their data. These protections often include requirements for developers to declare which permissions their apps use and how developers plan to use app data. Conversely, standalone app distribution sources like web browsers, messaging apps or file managers – which we commonly refer to as Internet-sideloading – do not offer the same rigorous requirements and operational reviews. Our data demonstrates that users who download from these sources today face unusually high security risks due to these missing protections. We recently launched enhanced Google Play Protect real-time scanning to help better protect users against novel malicious Internet-sideloaded apps. This enhancement is designed to address malicious apps that leverage various methods, such as AI, to avoid detection. This feature, now deployed on Android devices with Google Play Services in India, Thailand, Singapore and Brazil, has already made a significant impact on user safety. As a result of the real-time scanning enhancement, Play Protect has identified 515,000 new malicious apps and issued more than 3.1 million warnings or blocks of those apps. Play Protect is constantly improving its detection capabilities with each identified app, allowing us to strengthen our protections for the entire Android ecosystem. A new pilot to combat financial fraud Cybercriminals continue to invest in advanced financial fraud scams, costing consumers more than $1 trillion in losses. According to the 2023 Global State of Scams Report by the Global Anti-Scam Alliance, 78 percent of mobile users surveyed experienced at least one scam in the last year. Of those surveyed, 45 percent said they\'re experiencing more scams in the last 12 months. The Global Scam Report also found that scams were most often initia | Malware Threat Mobile | ★★ | |
|
2024-02-05 11:59:31 | Amélioration de l'interopérabilité entre la rouille et le C ++ Improving Interoperability Between Rust and C++ (lien direct) |
Publié par Lars Bergstrom & # 8211;Directeur, Android Platform Tools & amp;Bibliothèques et présidente du Rust Foundation Board En 2021, nous annoncé que Google rejoignait la Fondation Rust.À l'époque, Rust était déjà largement utilisée sur Android et d'autres produits Google.Notre annonce a souligné notre engagement à améliorer les examens de sécurité du code de la rouille et son interopérabilité avec le code C ++.La rouille est l'un des outils les plus forts que nous avons pour résoudre les problèmes de sécurité de la sécurité mémoire.Depuis cette annonce, les leaders de l'industrie et agences gouvernementales sentiment. Nous sommes ravis d'annoncer que Google a fourni une subvention de 1 million de dollars à la Rust Foundation pour soutenir les efforts qui amélioreront la capacité de Rust Code à interopérer avec les bases de code C ++ héritées existantes.Nous réapparaisons également notre engagement existant envers la communauté de la rouille open source en agrégant et en publiant Audits pour les caisses de rouille que nous utilisons dans les projets Google open-source.Ces contributions, ainsi que notre contributions précédentes à l'interopérabilité , ont-ellesenthousiasmé par l'avenir de la rouille. "Sur la base des statistiques historiques de la densité de la densité de vulnérabilité, Rust a empêché de manière proactive des centaines de vulnérabilités d'avoir un impact sur l'écosystème Android.Cet investissement vise à étendre l'adoption de la rouille sur divers composants de la plate-forme. » & # 8211;Dave Kleidermacher, vice-président de l'ingénierie, Android Security & AMP;Confidentialité Bien que Google ait connu la croissance la plus importante de l'utilisation de la rouille dans Android, nous continuons à augmenter son utilisation sur plus d'applications, y compris les clients et le matériel de serveur. «Bien que la rouille ne soit pas adaptée à toutes les applications de produits, la priorisation de l'interopérabilité transparente avec C ++ accélérera l'adoption de la communauté plus large, s'alignant ainsi sur les objectifs de l'industrie d'améliorer la sécurité mémoire.» & # 8211;Royal Hansen, vice-président de Google de la sécurité et de l'AMP;Sécurité L'outillage de rouille et l'écosystème prennent déjà en charge interopérabilité avec Android et avec un investissement continuDans des outils comme cxx , autocxx , bindgen , cbindgen , diplomate , et crubit, nous constatons des améliorations régulières de l'état d'interopérabilité de la rouille avec C ++.Au fur et à mesure que ces améliorations se sont poursuivies, nous avons constaté une réduction des obstacles à l'adoption et à l'adoption accélérée de la rouille.Bien que ces progrès à travers les nombreux outils se poursuivent, il ne se fait souvent que développer progressivement pour répondre aux besoins particuliers d'un projet ou d'une entreprise donnée. Afin d'accélérer à la fois l'adoption de la rouill | Tool Vulnerability Mobile | ★★★ | |
|
2024-02-01 13:40:22 | Le traité de la cybercriminalité des Nations Unies pourrait mettre en danger la sécurité du Web UN Cybercrime Treaty Could Endanger Web Security (lien direct) |
Royal Hansen, Vice President of Privacy, Safety and Security EngineeringThis week, the United Nations convened member states to continue its years-long negotiations on the UN Cybercrime Treaty, titled “Countering the Use of Information and Communications Technologies for Criminal Purposes.” As more aspects of our lives intersect with the digital sphere, law enforcement around the world has increasingly turned to electronic evidence to investigate and disrupt criminal activity. Google takes the threat of cybercrime very seriously, and dedicates significant resources to combating it. When governments send Google legal orders to disclose user data in connection with their investigations, we carefully review those orders to make sure they satisfy applicable laws, international norms, and Google\'s policies. We also regularly report the number of these orders in our Transparency Report. | Threat | ★★★ | |
|
2024-01-31 13:07:18 | Échelle de sécurité avec l'IA: de la détection à la solution Scaling security with AI: from detection to solution (lien direct) |
Dongge Liu and Oliver Chang, Google Open Source Security Team, Jan Nowakowski and Jan Keller, Machine Learning for Security TeamThe AI world moves fast, so we\'ve been hard at work keeping security apace with recent advancements. One of our approaches, in alignment with Google\'s Safer AI Framework (SAIF), is using AI itself to automate and streamline routine and manual security tasks, including fixing security bugs. Last year we wrote about our experiences using LLMs to expand vulnerability testing coverage, and we\'re excited to share some updates. Today, we\'re releasing our fuzzing framework as a free, open source resource that researchers and developers can use to improve fuzzing\'s bug-finding abilities. We\'ll also show you how we\'re using AI to speed up the bug patching process. By sharing these experiences, we hope to spark new ideas and drive innovation for a stronger ecosystem security.Update: AI-powered vulnerability discoveryLast August, we announced our framework to automate manual aspects of fuzz testing (“fuzzing”) that often hindered open source maintainers from fuzzing their projects effectively. We used LLMs to write project-specific code to boost fuzzing coverage and find more vulnerabilities. Our initial results on a subset of projects in our free OSS-Fuzz service | Vulnerability Patching Cloud | ★★ | |
|
2024-01-30 12:00:18 | Passer sans effort vers PassKeys sur des téléphones Pixel avec Google Password Manager Effortlessly upgrade to Passkeys on Pixel phones with Google Password Manager (lien direct) |
Posted by Sherif Hanna, Group Product Manager, Pixel Security
Helping Pixel owners upgrade to the easier, safer way to sign in
Your phone contains a lot of your personal information, from financial data to photos. Pixel phones are designed to help protect you and your data, and make security and privacy as easy as possible. This is why the Pixel team has been especially excited about passkeys-the easier, safer alternative to passwords.
Passkeys are safer because they\'re unique to each account, and are more resistant against online attacks such as phishing. They\'re easier to use because there\'s nothing for you to remember: when it\'s time to sign in, using a passkey is as simple as unlocking your device with your face or fingerprint, or your PIN/pattern/password.
Google is working to accelerate passkey adoption. We\'ve launched support for passkeys on Google platforms such as Android and Chrome, and recently we announced that we\'re making passkeys a default option across personal Google Accounts. We\'re also working with our partners across the industry to make passkeys available on more websites and apps.
Recently, we took things a step further. As part of last December\'s Pixel Feature Drop, we introduced a new feature to Google Password Manager: passkey upgrades. With this new feature, Google Password Manager will let you discover which of your accounts support passkeys, and help you upgrade with just a few taps.
This new passkey upgrade experience is now available on Pixel phones (starting from Pixel 5a) as well as Pixel Tablet. Google Password manager will incorporate these updates for other platforms in the future.
Best of all, today we\'re happy to announce that we\'ve teamed up with Adobe, Best Buy, DocuSign, eBay, Kayak, Money Forward, Nintendo, PayPal, Uber, Yahoo! Japan-and soon, TikTok as well, to help bring you this easy passkey upgrade experience and usher you into the passwordless future.
If you have an account with one of these early launch partners, Google Password Manager on Pixel will helpfully guide you to the exact location on the partner\'s website or app where you can upgrade to a passkey. There\'s no need to manually hunt for the option in acc |
Mobile | Uber | ★★★ |
|
2024-01-11 14:18:14 | MiraclePtr: protéger les utilisateurs contre les vulnérabilités sans utilisation sans plateformes MiraclePtr: protecting users from use-after-free vulnerabilities on more platforms (lien direct) |
Posted by Keishi Hattori, Sergei Glazunov, Bartek Nowierski on behalf of the MiraclePtr team
Welcome back to our latest update on MiraclePtr, our project to protect against use-after-free vulnerabilities in Google Chrome. If you need a refresher, you can read our previous blog post detailing MiraclePtr and its objectives.
More platforms
We are thrilled to announce that since our last update, we have successfully enabled MiraclePtr for more platforms and processes:
In June 2022, we enabled MiraclePtr for the browser process on Windows and Android.
In September 2022, we expanded its coverage to include all processes except renderer processes.
In June 2023, we enabled MiraclePtr for ChromeOS, macOS, and Linux.
Furthermore, we have changed security guidelines to downgrade MiraclePtr-protected issues by one severity level!
Evaluating Security Impact
First let\'s focus on its security impact. Our analysis is based on two primary information sources: incoming vulnerability reports and crash reports from user devices. Let\'s take a closer look at each of these sources and how they inform our understanding of MiraclePtr\'s effectiveness.
Bug reports
Chrome vulnerability reports come from various sources, such as:
Chrome Vulnerability Reward Program participants,
our fuzzing infrastructure,
internal and external teams investigating security incidents.
For the purposes of this analysis, we focus on vulnerabilities that affect platforms where MiraclePtr was enabled at the time the issues were reported. We also exclude bugs that occur inside a sandboxed renderer process. Since the initial launch of MiraclePtr in 2022, we have received 168 use-after-free reports matching our criteria.
What does the data tell us? MiraclePtr effectively mitigated 57% of these use-after-free vulnerabilities in privileged processes, exceeding our initial estimate of 50%. Reaching this level of effectiveness, however, required additional work. For instance, we not only rewrote class fields to use MiraclePtr, as discussed in the previous post, but also added MiraclePtr support for bound function arguments, such as Unretained pointers. These pointers have been a significant source of use-after-frees in Chrome, and the additional protection allowed us to mitigate 39 more issues.
Moreover, these vulnerability reports enable us to pinpoint areas needing improvement. We\'re actively working on adding support for select third-party libraries that have been a source of use-after-free bugs, as well as developing a more advanced rewriter tool that can handle transformations like converting std::vector into std::vector. We\'ve also made sever |
Tool Vulnerability Threat Mobile | ★★★ | |
|
2023-12-12 12:00:09 | Durcissant les bandes de base cellulaire dans Android Hardening cellular basebands in Android (lien direct) |
Posted by Ivan Lozano and Roger Piqueras Jover Android\'s defense-in-depth strategy applies not only to the Android OS running on the Application Processor (AP) but also the firmware that runs on devices. We particularly prioritize hardening the cellular baseband given its unique combination of running in an elevated privilege and parsing untrusted inputs that are remotely delivered into the device. This post covers how to use two high-value sanitizers which can prevent specific classes of vulnerabilities found within the baseband. They are architecture agnostic, suitable for bare-metal deployment, and should be enabled in existing C/C++ code bases to mitigate unknown vulnerabilities. Beyond security, addressing the issues uncovered by these sanitizers improves code health and overall stability, reducing resources spent addressing bugs in the future. An increasingly popular attack surface As we outlined previously, security research focused on the baseband has highlighted a consistent lack of exploit mitigations in firmware. Baseband Remote Code Execution (RCE) exploits have their own categorization in well-known third-party marketplaces with a relatively low payout. This suggests baseband bugs may potentially be abundant and/or not too complex to find and exploit, and their prominent inclusion in the marketplace demonstrates that they are useful. Baseband security and exploitation has been a recurring theme in security conferences for the last decade. Researchers have also made a dent in this area in well-known exploitation contests. Most recently, this area has become prominent enough that it is common to find practical baseband exploitation trainings in top security conferences. Acknowledging this trend, combined with the severity and apparent abundance of these vulnerabilities, last year we introduced updates to the severity guidelines of Android\'s Vulnerability Rewards Program (VRP). For example, we consider vulnerabilities allowing Remote Code Execution (RCE) in the cellular baseband to be of CRITICAL severity. Mitigating Vulnerability Root Causes with Sanitizers Common classes of vulnerabilities can be mitigated through the use of sanitizers provided by Clang-based toolchains. These sanitizers insert runtime checks against common classes of vulnerabilities. GCC-based toolchains may also provide some level of support for these flags as well, but will not be considered further in this post. We encourage you to check your toolchain\'s documentation. Two sanitizers included in Undefine | Tool Vulnerability Threat Mobile Prediction Conference | ★★★ | |
|
2023-11-29 12:00:03 | Amélioration de la résilience et de l'efficacité de la classification du texte avec RETVE Improving Text Classification Resilience and Efficiency with RETVec (lien direct) |
Elie Bursztein, Cybersecurity & AI Research Director, and Marina Zhang, Software EngineerSystems such as Gmail, YouTube and Google Play rely on text classification models to identify harmful content including phishing attacks, inappropriate comments, and scams. These types of texts are harder for machine learning models to classify because bad actors rely on adversarial text manipulations to actively attempt to evade the classifiers. For example, they will use homoglyphs, invisible characters, and keyword stuffing to bypass defenses. To help make text classifiers more robust and efficient, we\'ve developed a novel, multilingual text vectorizer called RETVec (Resilient & Efficient Text Vectorizer) that helps models achieve state-of-the-art classification performance and drastically reduces computational cost. Today, we\'re sharing how RETVec has been used to help protect Gmail inboxes.Strengthening the Gmail Spam Classifier with RETVec Figure 1. RETVec-based Gmail Spam filter improvements. |
Spam Mobile | ★★ | |
|
2023-11-20 11:49:31 | Deux ans plus tard: une base de référence qui fait grimper la sécurité de l'industrie Two years later: a baseline that drives up security for the industry (lien direct) |
Royal Hansen, Vice President of Privacy, Safety and Security Engineering, GoogleNearly half of third-parties fail to meet two or more of the Minimum Viable Secure Product controls. Why is this a problem? Because "98% of organizations have a relationship with at least one third-party that has experienced a breach in the last 2 years."In this post, we\'re excited to share the latest improvements to the Minimum Viable Secure Product (MVSP) controls. We\'ll also shed light on how adoption of MVSP has helped Google improve its security processes, and hope this example will help motivate third-parties to increase their adoption of MVSP controls and thus improve product security across the industry.About MVSPIn October 2021, Google publicly launched MVSP alongside launch partners. Our original goal remains unchanged: to provide a vendor-neutral application security baseline, designed to eliminate overhead, complexity, and confusion in the end-to-end process of onboarding third-party products and services. It covers themes such as procurement, security assessment, and contract negotiation. Improvements since launchAs part of MVSP\'s annual control review, and our core philosophy of evolution over revolution |
Vulnerability Conference | ★★ | |
|
2023-11-08 09:03:58 | Évolution de l'App Defence Alliance Evolving the App Defense Alliance (lien direct) |
Publié par Nataliya Stanetsky, Android Security and Privacy Team
L'App Defence Alliance (ADA), une collaboration à la tête de l'industrie Lancé Par Google en 2019, dédié à garantir la sécurité de l'écosystème de l'application, fait un pas en avant majeur.Nous sommes fiers de Annonce que l'App Defence Alliance se déplace sous l'égide de la Fondation Linux, avec Meta, Microsoft et Google en tant que membres de la direction fondatrice.
Cette migration stratégique représente un moment central dans le parcours de l'Alliance \\, ce qui signifie un engagement partagé par les membres pour renforcer la sécurité des applications et les normes connexes entre les écosystèmes.Cette évolution de l'App Defence Alliance nous permettra de favoriser une mise en œuvre plus collaborative des normes de l'industrie pour la sécurité des applications.
Uniter pour la sécurité des applications
Le paysage numérique évolue continuellement, tout comme les menaces pour la sécurité des utilisateurs.Avec la complexité toujours croissante des applications mobiles et l'importance croissante de la protection des données, c'est le moment idéal pour cette transition.La Fondation Linux est réputée pour son dévouement à favoriser des projets open source qui stimulent l'innovation, la sécurité et la durabilité.En combinant des forces avec des membres supplémentaires sous la Fondation Linux, nous pouvons nous adapter et répondre plus efficacement aux défis émergents.
L'engagement de la nouvelle application de défense de la Defence Alliance \\ est des membres de la direction & # 8211;Meta, Microsoft et Google & # 8211;est essentiel pour faire de cette transition une réalité.Avec une communauté membre couvrant 16 membres généraux et contributeurs supplémentaires, l'alliance soutiendra l'adoption à l'échelle de l'industrie des meilleures pratiques et directives de la sécurité des applications, ainsi que des contre-mesures contre les risques de sécurité émergents.
Poursuivant le programme d'atténuation des logiciels malveillants
L'App Defence Alliance a été formée avec la mission de réduire le risque de logiciels malveillants basés sur l'application et de mieux protéger les utilisateurs d'Android.La défense malveillante reste un objectif important pour Google et Android, et nous continuerons de nous associer étroitement avec les membres du programme d'atténuation des logiciels malveillants & # 8211;ESET, Lookout, McAfee, Trend Micro, Zimperium & # 8211;sur le partage direct du signal.La migration de l'ADA sous la Fondation Linux permettra un partage plus large de l'intelligence des menaces à travers les principaux partenaires et chercheurs écosystémiques.
en regardant vers l'avenir et en se connectant avec l'ADA
Nous vous invitons à rester connecté avec la nouvelle Alliance de défense de l'application sous l'égide de la Fondation Linux.Rejoignez la conversation pour aider à rendre les applications plus sécurisées.Avec le comité directeur, Alliance Partners et l'écosystème plus large, nous sommes impatients de créer des écosystèmes d'applications plus sûrs et dignes de confiance.
Posted by Nataliya Stanetsky, Android Security and Privacy Team The App Defense Alliance (ADA), an industry-leading collaboration launched by Google in 2019 dedicated to ensuring the safety of the app ecosystem, is taking a major step forward. We are proud to |
Malware Threat Mobile Prediction | ★★ | |
|
2023-11-07 14:06:03 | MTE - le chemin prometteur à suivre pour la sécurité de la mémoire MTE - The promising path forward for memory safety (lien direct) |
Posted by Andy Qin, Irene Ang, Kostya Serebryany, Evgenii Stepanov Since 2018, Google has partnered with ARM and collaborated with many ecosystem partners (SoCs vendors, mobile phone OEMs, etc.) to develop Memory Tagging Extension (MTE) technology. We are now happy to share the growing adoption in the ecosystem. MTE is now available on some OEM devices (as noted in a recent blog post by Project Zero) with Android 14 as a developer option, enabling developers to use MTE to discover memory safety issues in their application easily. The security landscape is changing dynamically, new attacks are becoming more complex and costly to mitigate. It\'s becoming increasingly important to detect and prevent security vulnerabilities early in the software development cycle and also have the capability to mitigate the security attacks at the first moment of exploitation in production.The biggest contributor to security vulnerabilities are memory safety related defects and Google has invested in a set of technologies to help mitigate memory safety risks. These include but are not limited to: Shifting to memory safe languages such as Rust as a proactive solution to prevent the new memory safety bugs from being introduced in the first place. Tools for detecting memory safety defects in the development stages and production environment, such as widely used sanitizer technologies1 (ASAN, HWASAN, GWP-ASAN, etc.) as well as fuzzing (with sanitizers enabled). Foundational technologies like MTE, which many experts believe is the most promising path forward for improving C/C++ software security and it can be deployed both in development and production at reasonably low cost. MTE is a hardware based capability that can detect unknown memory safety vulnerabilities in testing and/or mitigate them in production. It works by tagging the pointers and memory regions and comparing the tags to identify mismatches (details). In addition to the security benefits, MTE can also help ensure integrity because memory safety bugs remain one of the major contributors to silent data corruption that not only impact customer trust, but also cause lost productivity for software developers. At the moment, MTE is supported on some of the latest chipsets: Focusing on security for Android devices, the MediaTek Dimensity 9300 integrates support for MTE via ARM\'s latest v9 architecture (which is what Cortex-X4 and Cortex-A720 processors are based on). This feature can be switched on and off in the bootloader by users and developers instead of having it always on or always off. Tensor G3 integrates support for MTE only within the developer mode toggle. Feature can be activated by developers. For both chipsets, this feature can be switched on and off by developers, making it easier to find memory-related bugs during development and after deployment. MTE can help users stay safe while also improving time to market for OEMs.Application develope | Vulnerability Mobile | ★★★ | |
|
2023-11-03 16:37:53 | Certificats qualifiés avec des risques qualifiés Qualified certificates with qualified risks (lien direct) |
Publié par Chrome Security Team
L'amélioration de l'interopérabilité des services Web est un objectif important et digne.Nous pensons qu'il devrait être plus facile pour les gens de maintenir et de contrôler leurs identités numériques.Et nous apprécions que les décideurs politiques travaillant sur la législation sur le certificat numérique de l'Union européenne, connue sous le nom d'EIDAS, travaille à cet objectif.Cependant, une partie spécifique de la législation, article 45, entrave les navigateurs \\ 'la capacité à appliquer certaines exigences de sécurité sur les certificats, ce qui potentiellement retenir les progrès de la sécurité du Web pendant des décennies.Nous et de nombreux dirigeants passés et actuels de la communauté Web internationale ont des préoccupations importantes concernant l'impact de l'article 45 sur la sécurité.
Nous exhortons les législateurs à tenir compte du appelle des scientifiques et des experts en sécurité à réviser cette partie de la législation plutôt que d'éroderUtilisateurs \\ 'Confidentialité et sécurité sur le Web.
Posted by Chrome Security team Improving the interoperability of web services is an important and worthy goal. We believe that it should be easier for people to maintain and control their digital identities. And we appreciate that policymakers working on European Union digital certificate legislation, known as eIDAS, are working toward this goal. However, a specific part of the legislation, Article 45, hinders browsers\' ability to enforce certain security requirements on certificates, potentially holding back advances in web security for decades. We and many past and present leaders in the international web community have significant concerns about Article 45\'s impact on security. We urge lawmakers to heed the calls of scientists and security experts to revise this part of the legislation rather than erode users\' privacy and security on the web. |
Legislation | ★★ | |
|
2023-11-02 12:00:24 | Plus de moyens pour les utilisateurs d'identifier les applications testées sur la sécurité indépendante sur Google Play More ways for users to identify independently security tested apps on Google Play (lien direct) |
Posted by Nataliya Stanetsky, Android Security and Privacy Team
Keeping Google Play safe for users and developers remains a top priority for Google. As users increasingly prioritize their digital privacy and security, we continue to invest in our Data Safety section and transparency labeling efforts to help users make more informed choices about the apps they use.
Research shows that transparent security labeling plays a crucial role in consumer risk perception, building trust, and influencing product purchasing decisions. We believe the same principles apply for labeling and badging in the Google Play store. The transparency of an app\'s data security and privacy play a key role in a user\'s decision to download, trust, and use an app.
Highlighting Independently Security Tested VPN Apps
Last year, App Defense Alliance (ADA) introduced MASA (Mobile App Security Assessment), which allows developers to have their apps independently validated against a global security standard. This signals to users that an independent third-party has validated that the developers designed their apps to meet these industry mobile security and privacy minimum best practices and the developers are going the extra mile to identify and mitigate vulnerabilities. This, in turn, makes it harder for attackers to reach users\' devices and improves app quality across the ecosystem. Upon completion of the successful validation, Google Play gives developers the option to declare an “Independent security review” badge in its Data Safety section, as shown in the image below. While certification to baseline security standards does not imply that a product is free of vulnerabilities, the badge associated with these validated apps helps users see at-a-glance that a developer has prioritized security and privacy practices and committed to user safety.
To help give users a simplified view of which apps have undergone an independent security validation, we\'re introducing a new Google Play store banner for specific app types, starting with VPN apps. We\'ve launched this banner beginning with VPN apps due to the sensitive and significant amount of user data these apps handle. When a user searches for VPN apps, they will now see a banner at the top of Google Play that educates them about the “Independent security review” badge in the Data Safety Section. Users also have the ability to “Learn More”, which redirects them to the App Validation Directory, a centralized place to view all VPN apps that have been independently security reviewed. Users can also discover additional technical assessment details in the App Validation Directory, helping them to make more informed decisions about what VPN apps to download, use, and trust with their data.
|
Tool Vulnerability Mobile Technical | ★★ | |
|
2023-10-26 08:49:41 | Increasing transparency in AI security (lien direct) | Mihai Maruseac, Sarah Meiklejohn, Mark Lodato, Google Open Source Security Team (GOSST)New AI innovations and applications are reaching consumers and businesses on an almost-daily basis. Building AI securely is a paramount concern, and we believe that Google\'s Secure AI Framework (SAIF) can help chart a path for creating AI applications that users can trust. Today, we\'re highlighting two new ways to make information about AI supply chain security universally discoverable and verifiable, so that AI can be created and used responsibly. The first principle of SAIF is to ensure that the AI ecosystem has strong security foundations. In particular, the software supply chains for components specific to AI development, such as machine learning models, need to be secured against threats including model tampering, data poisoning, and the production of harmful content. Even as machine learning and artificial intelligence continue to evolve rapidly, some solutions are now within reach of ML creators. We\'re building on our prior work with the Open Source Security Foundation to show how ML model creators can and should protect against ML supply chain attacks by using | Malware Tool Vulnerability Threat Cloud | ★★ | |
|
2023-10-26 08:00:33 | Google\\'s reward criteria for reporting bugs in AI products (lien direct) | Eduardo Vela, Jan Keller and Ryan Rinaldi, Google Engineering In September, we shared how we are implementing the voluntary AI commitments that we and others in industry made at the White House in July. One of the most important developments involves expanding our existing Bug Hunter Program to foster third-party discovery and reporting of issues and vulnerabilities specific to our AI systems. Today, we\'re publishing more details on these new reward program elements for the first time. Last year we issued over $12 million in rewards to security researchers who tested our products for vulnerabilities, and we expect today\'s announcement to fuel even greater collaboration for years to come. What\'s in scope for rewards In our recent AI Red Team report, we identified common tactics, techniques, and procedures (TTPs) that we consider most relevant and realistic for real-world adversaries to use against AI systems. The following table incorporates shared learnings from | Tool Vulnerability | ★★ | |
|
2023-10-25 08:00:33 | Déclaration conjointe de l'industrie des principes de sécurité IoT des consommateurs Joint Industry statement of support for Consumer IoT Security Principles (lien direct) |
David Kleidermacher, VP Engineering, Android Security & amp;Confidentialité et sécurité DSPA & amp;Confidentialité, et Eugene Liderman, directeur, stratégie de sécurité Android la semaine dernière à Singapour Cyber Week et Conference de sécuritét de la sécurité , la communauté internationale s'est rassemblée pour discuter de la cybersécuritéSujets chauds de la journée.Au milieu d'un certain nombre de discussions importantes en cybersécurité, nous voulons mettre en évidence les progrès sur la sécurité des périphériques connectés démontré par & nbsp;Principes conjoints de l'industrie pour la transparence de la sécurité IoT.L'avenir des appareils connectés offre un énorme potentiel d'innovation et d'amélioration de la qualité de vie.Mettre un projecteur sur la sécurité de l'IoT des consommateurs est un aspect clé de la réalisation de ces avantages.La concurrence sur le marché peut être un moteur important des améliorations de la sécurité, les consommateurs sont autorisés et motivés à prendre des décisions d'achat éclairées en fonction de la sécurité des appareils. & Nbsp; Comme avec les autres initiatives de transparence de la sécurité IoT dans le monde, il est idéal de voir ce sujet couvert lors des deux conférences cette semaine.Les principes d'étiquetage de la sécurité IoT ci-dessous visent à aider à améliorer la sensibilisation aux consommateurs et à favoriser la concurrence du marché en fonction de la sécurité. Pour aider les consommateurs à prendre une décision d'achat éclairée, ils devraient recevoir des informations claires, cohérentes et exploitables sur la sécurité de l'appareil (par exemple la période de soutien à la sécurité, le support d'authentification, l'assurance cryptographique)Avant l'achat - un mécanisme de communication et de transparence communément appelé «étiquette» ou «étiquetage», bien que la communication ne soit pas simplement un autocollant imprimé sur l'emballage de produit physique.Bien qu'une étiquette IoT ne résoudra pas le problème de la sécurité de l'IoT à elle seule, la transparence peut à la fois aider à éduquer les consommateurs et à faciliter également la coordination des responsabilités de sécurité entre tous les composants d'un écosystème de dispositif connecté. Notre objectif est de renforcer la sécurité des appareils IoT et des écosystèmes pour protéger les individus et les organisations,et pour libérer le plein avantage futur de l'IoT.Les programmes d'étiquetage de sécurité peuvent prendre en charge les décisions d'achat des consommateurs qui stimulent les améliorations de la sécurité, mais uniquement si l'étiquette est crédible, exploitable et facilement comprise.Nous espérons que le secteur public et l'industrie pourront travailler ensemble pour stimuler les politiques harmonisées qui atteignent cet objectif. & Nbsp; signé, google bras | ★★ | ||
|
2023-10-18 12:00:27 | Google Play amélioré Protéger la numérisation en temps réel pour les installations d'applications Enhanced Google Play Protect real-time scanning for app installs (lien direct) |
Posted by Steve Kafka, Group Product Manager and Roman Kirillov, Senior Engineering Manager
Mobile devices have supercharged our modern lives, helping us do everything from purchasing goods in store and paying bills online to storing financial data, health records, passwords and pictures. According to Data.ai, the pandemic accelerated existing mobile habits – with app categories like finance growing 25% year-over-year and users spending over 100 billion hours in shopping apps. It\'s now even more important that data is protected so that bad actors can\'t access the information.
Powering up Google Play Protect
Google Play Protect is built-in, proactive protection against malware and unwanted software and is enabled on all Android devices with Google Play Services. Google Play Protect scans 125 billion apps daily to help protect you from malware and unwanted software. If it finds a potentially harmful app, Google Play Protect can take certain actions such as sending you a warning, preventing an app install, or disabling the app automatically.
To try and avoid detection by services like Play Protect, cybercriminals are using novel malicious apps available outside of Google Play to infect more devices with polymorphic malware, which can change its identifiable features. They\'re turning to social engineering to trick users into doing something dangerous, such as revealing confidential information or downloading a malicious app from ephemeral sources – most commonly via links to download malicious apps or downloads directly through messaging apps.
For this reason, Google Play Protect has always also offered users protection outside of Google Play. It checks your device for potentially harmful apps regardless of the install source when you\'re online or offline as well. Previously, when installing an app, Play Protect conducted a real-time check and warned users when it identified an app known to be malicious from existing scanning intelligence or was identified as suspicious from our on-device machine learning, similarity comparisons, and other techniques that we are always evolving.
Today, we are making Google Play Protect\'s security capabilities even more powerful with real-time scanning at the code-level to combat novel malicious apps. Google Play Protect will now recommend a real-time app scan when installing apps that have never been scanned before to help detect emerging threats.
Scanning will extract important signals from the app and send them to the Play Protect backend infrastructure for a code-level evaluation. Once the real-time analysis is complete, users will get a result letting them know if the app looks safe to install or if the scan determined the app is potentially harmful. This enhancement will help better protect users against malicious polymorphic apps that leverage various methods, such as AI, to be altered to avoid detection.
Our security protections and machine learning algorithms learn from each app |
Spam Malware | ★★ | |
|
2023-10-10 15:39:40 | Échelle au-delà ducorp avec les politiques de contrôle d'accès assistées par l'IA Scaling BeyondCorp with AI-Assisted Access Control Policies (lien direct) |
Ayush Khandelwal, Software Engineer, Michael Torres, Security Engineer, Hemil Patel, Technical Product Expert, Sameer Ladiwala, Software EngineerIn July 2023, four Googlers from the Enterprise Security and Access Security organizations developed a tool that aimed at revolutionizing the way Googlers interact with Access Control Lists - SpeakACL. This tool, awarded the Gold Prize during Google\'s internal Security & AI Hackathon, allows developers to create or modify security policies using simple English instructions rather than having to learn system-specific syntax or complex security principles. This can save security and product teams hours of time and effort, while helping to protect the information of their users by encouraging the reduction of permitted access by adhering to the principle of least privilege.Access Control Policies in BeyondCorpGoogle requires developers and owners of enterprise applications to define their own access control policies, as described in BeyondCorp: The Access Proxy. We have invested in reducing the difficulty of self-service ACL and ACL test creation to encourage these service owners to define least privilege access control policies. However, it is still challenging to concisely transform their intent into the language acceptable to the access control engine. Additional complexity is added by the variety of engines, and corresponding policy definition languages that target different access control domains (i.e. websites, networks, RPC servers).To adequately implement an access control policy, service developers are expected to learn various policy definition languages and their associated syntax, in addition to sufficiently understanding security concepts. As this takes time away from core developer work, it is not the most efficient use of developer time. A solution was required to remove these challenges so developers can focus on building innovative tools and products.Making it WorkWe built a prototype interface for interactively defining and modifying access control policies for the | Tool Vulnerability | ★★★ | |
|
2023-10-09 12:30:13 | Rust à métal nu dans Android Bare-metal Rust in Android (lien direct) |
Posted by Andrew Walbran, Android Rust Team
Last year we wrote about how moving native code in Android from C++ to Rust has resulted in fewer security vulnerabilities. Most of the components we mentioned then were system services in userspace (running under Linux), but these are not the only components typically written in memory-unsafe languages. Many security-critical components of an Android system run in a “bare-metal” environment, outside of the Linux kernel, and these are historically written in C. As part of our efforts to harden firmware on Android devices, we are increasingly using Rust in these bare-metal environments too.
To that end, we have rewritten the Android Virtualization Framework\'s protected VM (pVM) firmware in Rust to provide a memory safe foundation for the pVM root of trust. This firmware performs a similar function to a bootloader, and was initially built on top of U-Boot, a widely used open source bootloader. However, U-Boot was not designed with security in a hostile environment in mind, and there have been numerous security vulnerabilities found in it due to out of bounds memory access, integer underflow and memory corruption. Its VirtIO drivers in particular had a number of missing or problematic bounds checks. We fixed the specific issues we found in U-Boot, but by leveraging Rust we can avoid these sorts of memory-safety vulnerabilities in future. The new Rust pVM firmware was released in Android 14.
As part of this effort, we contributed back to the Rust community by using and contributing to existing crates where possible, and publishing a number of new crates as well. For example, for VirtIO in pVM firmware we\'ve spent time fixing bugs and soundness issues in the existing virtio-drivers crate, as well as adding new functionality, and are now helping maintain this crate. We\'ve published crates for making PSCI and other Arm SMCCC calls, and for managing page tables. These are just a start; we plan to release more Rust crates to support bare-metal programming on a range of platforms. These crates are also being used outside of Android, such as in Project Oak and the bare-metal section of our Comprehensive Rust course.
Training engineers
Many engineers have been positively surprised by how p |
Tool Vulnerability | ★★ | |
|
2023-10-06 10:21:05 | Élargir notre programme de récompense d'exploitation à Chrome et à Cloud Expanding our exploit reward program to Chrome and Cloud (lien direct) |
Stephen Roettger and Marios Pomonis, Google Software EngineersIn 2020, we launched a novel format for our vulnerability reward program (VRP) with the kCTF VRP and its continuation kernelCTF. For the first time, security researchers could get bounties for n-day exploits even if they didn\'t find the vulnerability themselves. This format proved valuable in improving our understanding of the most widely exploited parts of the linux kernel. Its success motivated us to expand it to new areas and we\'re now excited to announce that we\'re extending it to two new targets: v8CTF and kvmCTF.Today, we\'re launching v8CTF, a CTF focused on V8, the JavaScript engine that powers Chrome. kvmCTF is an upcoming CTF focused on Kernel-based Virtual Machine (KVM) that will be released later in the year.As with kernelCTF, we will be paying bounties for successful exploits against these platforms, n-days included. This is on top of any existing rewards for the vulnerabilities themselves. For example, if you find a vulnerability in V8 and then write an exploit for it, it can be eligible under both the Chrome VRP and the v8CTF.We\'re always looking for ways to improve the security posture of our products, and we want to learn from the security community to understand how they will approach this challenge. If you\'re successful, you\'ll not only earn a reward, but you\'ll also help us make our products more secure for everyone. This is also a good opportunity to learn about technologies and gain hands-on experience exploiting them.Besides learning about exploitation techniques, we\'ll also leverage this program to experiment with new mitigation ideas and see how they perform against real-world exploits. For mitigations, it\'s crucial to assess their effectiveness early on in the process, and you can help us battle test them.How do I participate? | Vulnerability Cloud | ★★ | |
|
2023-09-27 12:51:29 | Les lacunes de sécurité et de confidentialité SMS montrent clairement que les utilisateurs ont besoin d'une mise à niveau de messagerie SMS Security & Privacy Gaps Make It Clear Users Need a Messaging Upgrade (lien direct) |
Posted by Eugene Liderman and Roger Piqueras Jover
SMS texting is frozen in time.
People still use and rely on trillions of SMS texts each year to exchange messages with friends, share family photos, and copy two-factor authentication codes to access sensitive data in their bank accounts. It\'s hard to believe that at a time where technologies like AI are transforming our world, a forty-year old mobile messaging standard is still so prevalent.
Like any forty-year-old technology, SMS is antiquated compared to its modern counterparts. That\'s especially concerning when it comes to security.
The World Has Changed, But SMS Hasn\'t Changed With It
According to a recent whitepaper from Dekra, a safety certifications and testing lab, the security shortcomings of SMS can notably lead to:
SMS Interception: Attackers can intercept SMS messages by exploiting vulnerabilities in mobile carrier networks. This can allow them to read the contents of SMS messages, including sensitive information such as two-factor authentication codes, passwords, and credit card numbers due to the lack of encryption offered by SMS.
SMS Spoofing: Attackers can spoof SMS messages to launch phishing attacks to make it appear as if they are from a legitimate sender. This can be used to trick users into clicking on malicious links or revealing sensitive information. And because carrier networks have independently developed their approaches to deploying SMS texts over the years, the inability for carriers to exchange reputation signals to help identify fraudulent messages has made it tough to detect spoofed senders distributing potentially malicious messages.
These findings add to the well-established facts about SMS\' weaknesses, lack of encryption chief among them.
Dekra also compared SMS against a modern secure messaging protocol and found it lacked any built-in security functionality. According to Dekra, SMS users can\'t answer \'yes\' to any of the following basic security questions:
Confidentiality: Can I trust that no one else can read my SMSs?
Integrity: Can I trust that the content of the SMS that I receive is not modified?
Authentication: Can I trust the identity of the sender of the SMS that I receive?
But this isn\'t just theoretical: cybercriminals have also caught on to the lack of security protections SMS provides and have repeatedly exploited its weakness. Both novice hackers and advanced threat actor groups (such as UNC3944 / Scattered Spider and APT41 investigated by Mandiant, part of Google Cloud) leverage the security deficiencies in SMS to launch different |
Vulnerability Threat Studies | APT 41 | ★★★ |
|
2023-09-21 12:00:57 | Échec de l'adoption de la rouille grâce à la formation Scaling Rust Adoption Through Training (lien direct) |
Posted by Martin Geisler, Android team Android 14 is the third major Android release with Rust support. We are already seeing a number of benefits: Productivity: Developers quickly feel productive writing Rust. They report important indicators of development velocity, such as confidence in the code quality and ease of code review. Security: There has been a reduction in memory safety vulnerabilities as we shift more development to memory safe languages. These positive early results provided an enticing motivation to increase the speed and scope of Rust adoption. We hoped to accomplish this by investing heavily in training to expand from the early adopters. Scaling up from Early Adopters Early adopters are often willing to accept more risk to try out a new technology. They know there will be some inconveniences and a steep learning curve but are willing to learn, often on their own time. Scaling up Rust adoption required moving beyond early adopters. For that we need to ensure a baseline level of comfort and productivity within a set period of time. An important part of our strategy for accomplishing this was training. Unfortunately, the type of training we wanted to provide simply didn\'t exist. We made the decision to write and implement our own Rust training. Training Engineers Our goals for the training were to: Quickly ramp up engineers: It is hard to take people away from their regular work for a long period of time, so we aimed to provide a solid foundation for using Rust in days, not weeks. We could not make anybody a Rust expert in so little time, but we could give people the tools and foundation needed to be productive while they continued to grow. The goal is to enable people to use Rust to be productive members of their teams. The time constraints meant we couldn\'t teach people programming from scratch; we also decided not to teach macros or unsafe Rust in detail. Make it engaging (and fun!): We wanted people to see a lot of Rust while also getting hands-on experience. Given the scope and time constraints mentioned above, the training was necessarily information-dense. This called for an interactive setting where people could quickly ask questions to the instructor. Research shows that retention improves when people can quickly verify assumptions and practice new concepts. Make it relevant for Android: The Android-specific tooling for Rust was already documented, but we wanted to show engineers how to use it via worked examples. We also wanted to document emerging standards, such as using thiserror and anyhow crates for error handling. Finally, because Rust is a new language in the Android Platform (AOSP), we needed to show how to interoperate with existing languages such as Java and C++. With those three goals as a starting point, we looked at the existing material and available tools. Existing Material Documentation is a key value of the Rust community and there are many great resources available for learning Rust. First, there is the freely available Rust Book, which covers almost all of the language. Second, the standard library is extensively documented. Because we knew our target audience, we could make stronger assumptions than most material found online. We created the course for engineers with at least 2–3 years of coding experience in either C, C++, or Java. This allowed us to move | Tool | ★★ | |
|
2023-09-15 14:11:38 | Capslock: De quoi votre code est-il vraiment capable? Capslock: What is your code really capable of? (lien direct) |
Jess McClintock and John Dethridge, Google Open Source Security Team, and Damien Miller, Enterprise Infrastructure Protection TeamWhen you import a third party library, do you review every line of code? Most software packages depend on external libraries, trusting that those packages aren\'t doing anything unexpected. If that trust is violated, the consequences can be huge-regardless of whether the package is malicious, or well-intended but using overly broad permissions, such as with Log4j in 2021. Supply chain security is a growing issue, and we hope that greater transparency into package capabilities will help make secure coding easier for everyone.Avoiding bad dependencies can be hard without appropriate information on what the dependency\'s code actually does, and reviewing every line of that code is an immense task. Every dependency also brings its own dependencies, compounding the need for review across an expanding web of transitive dependencies. But what if there was an easy way to know the capabilities–the privileged operations accessed by the code–of your dependencies? Capslock is a capability analysis CLI tool that informs users of privileged operations (like network access and arbitrary code execution) in a given package and its dependencies. Last month we published the alpha version of Capslock for the Go language, which can analyze and report on the capabilities that are used beneath the surface of open source software. | Tool Vulnerability | ★★ | |
|
2023-08-29 12:06:35 | Android se lance à fond dans le Fuzzing Android Goes All-in on Fuzzing (lien direct) |
Posted by Jon Bottarini and Hamzeh Zawawy, Android Security
Fuzzing is an effective technique for finding software vulnerabilities. Over the past few years Android has been focused on improving the effectiveness, scope, and convenience of fuzzing across the organization. This effort has directly resulted in improved test coverage, fewer security/stability bugs, and higher code quality. Our implementation of continuous fuzzing allows software teams to find new bugs/vulnerabilities, and prevent regressions automatically without having to manually initiate fuzzing runs themselves. This post recounts a brief history of fuzzing on Android, shares how Google performs fuzzing at scale, and documents our experience, challenges, and success in building an infrastructure for automating fuzzing across Android. If you\'re interested in contributing to fuzzing on Android, we\'ve included instructions on how to get started, and information on how Android\'s VRP rewards fuzzing contributions that find vulnerabilities.
A Brief History of Android Fuzzing
Fuzzing has been around for many years, and Android was among the early large software projects to automate fuzzing and prioritize it similarly to unit testing as part of the broader goal to make Android the most secure and stable operating system. In 2019 Android kicked off the fuzzing project, with the goal to help institutionalize fuzzing by making it seamless and part of code submission. The Android fuzzing project resulted in an infrastructure consisting of Pixel phones and Google cloud based virtual devices that enabled scalable fuzzing capabilities across the entire Android ecosystem. This project has since grown to become the official internal fuzzing infrastructure for Android and performs thousands of fuzzing hours per day across hundreds of fuzzers.
Under the Hood: How Is Android Fuzzed
Step 1: Define and find all the fuzzers in Android repo
The first step is to integrate fuzzing into the Android build system (Soong) to enable build fuzzer binaries. While developers are busy adding features to their codebase, they can include a fuzzer to fuzz their code and submit the fuzzer alongside the code they have developed. Android Fuzzing uses a build rule called cc_fuzz (see example below). cc_fuzz (we also support rust_fuzz and java_fuzz) defines a Soong module with source file(s) and dependencies that can be built into a binary.
cc_fuzz {
name: "fuzzer_foo",
srcs: [
"fuzzer_foo.cpp",
],
static_libs: [
"libfoo",
],
host_supported: true,
}
A packaging rule in Soong finds all of these cc_fuzz definitions and builds them automatically. The actual fuzzer structure itself is very simple and consists of one main method (LLVMTestOneInput):
#include
#include
extern "C" int LLVMFuzzerTestOneInput(
const uint8_t *data,
size_t size) {
// Here you invoke the code to be fuzzed.
return 0;
}
This fuzzer gets automatically built into a binary and along with its static/dynamic dependencies (as specified in the Android build file) are pack |
Vulnerability Cloud | ★★ | |
|
2023-08-16 13:03:58 | Fuzzing à propulsion AI: brisant la barrière de chasse aux insectes AI-Powered Fuzzing: Breaking the Bug Hunting Barrier (lien direct) |
Dongge Liu, Jonathan Metzman, Oliver Chang, Google Open Source Security Team Since 2016, OSS-Fuzz has been at the forefront of automated vulnerability discovery for open source projects. Vulnerability discovery is an important part of keeping software supply chains secure, so our team is constantly working to improve OSS-Fuzz. For the last few months, we\'ve tested whether we could boost OSS-Fuzz\'s performance using Google\'s Large Language Models (LLM). This blog post shares our experience of successfully applying the generative power of LLMs to improve the automated vulnerability detection technique known as fuzz testing (“fuzzing”). By using LLMs, we\'re able to increase the code coverage for critical projects using our OSS-Fuzz service without manually writing additional code. Using LLMs is a promising new way to scale security improvements across the over 1,000 projects currently fuzzed by OSS-Fuzz and to remove barriers to future projects adopting fuzzing. LLM-aided fuzzingWe created the OSS-Fuzz service to help open source developers find bugs in their code at scale-especially bugs that indicate security vulnerabilities. After more than six years of running OSS-Fuzz, we now support over 1,000 open source projects with continuous fuzzing, free of charge. As the Heartbleed vulnerability showed us, bugs that could be easily found with automated fuzzing can have devastating effects. For most open source developers, setting up their own fuzzing solution could cost time and resources. With OSS-Fuzz, developers are able to integrate their project for free, automated bug discovery at scale. | Vulnerability Cloud | ★★ | |
|
2023-08-15 17:57:56 | Vers les clés de sécurité résilientes quantiques Toward Quantum Resilient Security Keys (lien direct) |
Elie Bursztein, cybersecurity and AI research director, Fabian Kaczmarczyck, software engineerAs part of our effort to deploy quantum resistant cryptography, we are happy to announce the release of the first quantum resilient FIDO2 security key implementation as part of OpenSK, our open source security key firmware. This open-source hardware optimized implementation uses a novel ECC/Dilithium hybrid signature schema that benefits from the security of ECC against standard attacks and Dilithium\'s resilience against quantum attacks. This schema was co-developed in partnership with the ETH Zürich and won the ACNS secure cryptographic implementation workshop best paper. Quantum processorAs progress toward practical quantum computers is accelerating, preparing for their advent is becoming a more pressing issue as time passes. In particular, standard public key cryptography which was designed to protect against traditional computers, will not be able to withstand quantum |
★★ | ||
|
2023-08-10 12:01:36 | Rendre le chrome plus sécurisé en apportant une épingle clé sur Android Making Chrome more secure by bringing Key Pinning to Android (lien direct) |
Posted by David Adrian, Joe DeBlasio and Carlos Joan Rafael Ibarra Lopez, Chrome Security
Chrome 106 added support for enforcing key pins on Android by default, bringing Android to parity with Chrome on desktop platforms. But what is key pinning anyway?
One of the reasons Chrome implements key pinning is the “rule of two”. This rule is part of Chrome\'s holistic secure development process. It says that when you are writing code for Chrome, you can pick no more than two of: code written in an unsafe language, processing untrustworthy inputs, and running without a sandbox. This blog post explains how key pinning and the rule of two are related.
The Rule of Two
Chrome is primarily written in the C and C++ languages, which are vulnerable to memory safety bugs. Mistakes with pointers in these languages can lead to memory being misinterpreted. Chrome invests in an ever-stronger multi-process architecture built on sandboxing and site isolation to help defend against memory safety problems. Android-specific features can be written in Java or Kotlin. These languages are memory-safe in the common case. Similarly, we\'re working on adding support to write Chrome code in Rust, which is also memory-safe.
Much of Chrome is sandboxed, but the sandbox still requires a core high-privilege “broker” process to coordinate communication and launch sandboxed processes. In Chrome, the broker is the browser process. The browser process is the source of truth that allows the rest of Chrome to be sandboxed and coordinates communication between the rest of the processes.
If an attacker is able to craft a malicious input to the browser process that exploits a bug and allows the attacker to achieve remote code execution (RCE) in the browser process, that would effectively give the attacker full control of the victim\'s Chrome browser and potentially the rest of the device. Conversely, if an attacker achieves RCE in a sandboxed process, such as a renderer, the attacker\'s capabilities are extremely limited. The attacker cannot reach outside of the sandbox unless they can additionally exploit the sandbox itself.
Without sandboxing, which limits the actions an attacker can take, and without memory safety, which removes the ability of a bug to disrupt the intended control flow of the program, the rule of two requires that the browser process does not handle untrustworthy inputs. The relative risks between sandboxed processes and the browser process are why the browser process is only allowed to parse trustworthy inputs and specific IPC messages.
Trustworthy inputs are defined extremely strictly: A “trustworthy source” means that Chrome can prove that the data comes from Google. Effectively, this means that in situations where the browser process needs access to data from e |
Tool | ★★ | |
|
2023-08-08 13:33:00 | Chute et zenbleed: Googlers aide à sécuriser l'écosystème Downfall and Zenbleed: Googlers helping secure the ecosystem (lien direct) |
Tavis Ormandy, Software Engineer and Daniel Moghimi, Senior Research ScientistFinding and mitigating security vulnerabilities is critical to keeping Internet users safe. However, the more complex a system becomes, the harder it is to secure-and that is also the case with computing hardware and processors, which have developed highly advanced capabilities over the years. This post will detail this trend by exploring Downfall and Zenbleed, two new security vulnerabilities (one of which was disclosed today) that prior to mitigation had the potential to affect billions of personal and cloud computers, signifying the importance of vulnerability research and cross-industry collaboration. Had these vulnerabilities not been discovered by Google researchers, and instead by adversaries, they would have enabled attackers to compromise Internet users. For both vulnerabilities, Google worked closely with our partners in the industry to develop fixes, deploy mitigations and gather details to share widely and better secure the ecosystem.What are Downfall and Zenbleed?Downfall (CVE-2022-40982) and Zenbleed (CVE-2023-20593) are two different vulnerabilities affecting CPUs - Intel Core (6th - 11th generation) and AMD Zen2, respectively. They allow an attacker to violate the software-hardware boundary established in modern processors. This could allow an attacker to access data in internal hardware registers that hold information belonging to other users of the system (both across different virtual machines and different processes). These vulnerabilities arise from complex optimizations in modern CPUs tha | Vulnerability Prediction Cloud | ★★ | |
|
2023-08-08 11:59:13 | Android 14 présente les fonctionnalités de sécurité de la connectivité cellulaire en son genre Android 14 introduces first-of-its-kind cellular connectivity security features (lien direct) |
Posted by Roger Piqueras Jover, Yomna Nasser, and Sudhi Herle
Android is the first mobile operating system to introduce advanced cellular security mitigations for both consumers and enterprises. Android 14 introduces support for IT administrators to disable 2G support in their managed device fleet. Android 14 also introduces a feature that disables support for null-ciphered cellular connectivity.
Hardening network security on Android
The Android Security Model assumes that all networks are hostile to keep users safe from network packet injection, tampering, or eavesdropping on user traffic. Android does not rely on link-layer encryption to address this threat model. Instead, Android establishes that all network traffic should be end-to-end encrypted (E2EE).
When a user connects to cellular networks for their communications (data, voice, or SMS), due to the distinctive nature of cellular telephony, the link layer presents unique security and privacy challenges. False Base Stations (FBS) and Stingrays exploit weaknesses in cellular telephony standards to cause harm to users. Additionally, a smartphone cannot reliably know the legitimacy of the cellular base station before attempting to connect to it. Attackers exploit this in a number of ways, ranging from traffic interception and malware sideloading, to sophisticated dragnet surveillance.
Recognizing the far reaching implications of these attack vectors, especially for at-risk users, Android has prioritized hardening cellular telephony. We are tackling well-known insecurities such as the risk presented by 2G networks, the risk presented by null ciphers, other false base station (FBS) threats, and baseband hardening with our ecosystem partners.
2G and a history of inherent security risk
The mobile ecosystem is rapidly adopting 5G, the latest wireless standard for mobile, and many carriers have started to turn down 2G service. In the United States, for example, most major carriers have shut down 2G networks. However, all existing mobile devices still have support for 2G. As a result, when available, any mobile device will connect to a 2G network. This occurs automatically when 2G is the only network available, but this can also be remotely triggered in a malicious attack, silently inducing devices to downgrade to 2G-only connectivity and thus, ignoring any non-2G network. This behavior happens regardless of whether local operators have already sunset their 2G infrastructure.
2G networks, first implemented in 1991, do not provide the same level of security as subsequent mobile generat |
Malware Tool Threat Conference | ★★★ | |
|
2023-08-08 11:59:04 | Une mise à jour des mises à jour de la sécurité Chrome & # 8211;Expédition des correctifs de sécurité à vous plus rapidement An update on Chrome Security updates – shipping security fixes to you faster (lien direct) |
Posted by Amy Ressler, Chrome Security Team To get security fixes to you faster, starting now in Chrome 116, Chrome is shipping weekly Stable channel updates. Chrome ships a new milestone release every four weeks. In between those major releases, we ship updates to address security and other high impact bugs. We currently schedule one of these Stable channel updates (or “Stable Refresh”) between each milestone. Starting in Chrome 116, Stable updates will be released every week between milestones. This should not change how you use or update Chrome, nor is the frequency of milestone releases changing, but it does mean security fixes will get to you faster. Reducing the Patch Gap Chromium is the open source project which powers Chrome and many other browsers. Anyone can view the source code, submit changes for review, and see the changes made by anyone else, even security bug fixes. Users of our Canary (and Beta) channels receive those fixes and can sometimes give us early warning of unexpected stability, compatibility, or performance problems in advance of the fix reaching the Stable channel. This openness has benefits in testing fixes and discovering bugs, but comes at a cost: bad actors could possibly take advantage of the visibility into these fixes and develop exploits to apply against browser users who haven\'t yet received the fix. This exploitation of a known and patched security issue is referred to as n-day exploitation. That\'s why we believe it\'s really important to ship security fixes as soon as possible, to minimize this “patch gap”. When a Chrome security bug is fixed, the fix is landed in the public Chromium source code repository. The fix is then publicly accessible and discoverable. After the patch is landed, individuals across Chrome are working to test and verify the patch, and evaluate security bug fixes for backporting to affected release branches. Security fixes impacting Stable channel then await the next Stable channel update once they have been backported. The time between the patch being landed and shipped in a Stable channel update is the patch gap. Chrome began releasing Stable channel updates every two weeks in 2020, with Chrome 77, as a way to help reduce the patch gap. Before Chrome 77, our patch gap averaged 35 days. Since moving the biweekly release cadence, the patch gap has been reduced to around 15 days. The switch to weekly updates allows us to ship security fixes even faster, and further reduce the patch gap. While we can\'t fully remove the potential for n-day exploitation, a weekly Chrome security update cadence allows up to ship security fixes 3.5 days sooner on average, greatly reducing the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult. Getting Fixes to You Faster Not all security bug fixes are used for n-day exploitation. But we don\'t know which bugs are exploited in practice, and which aren\'t, so we treat all critical and high severity bugs as if they will be exploited. A lot of work goes into making sure these bugs get triaged and fixed as soon as possible. Rather than having fixes sitting and waiting to be included in the next bi-weekly update, weekly updates will allow us to get important security bug fixes to you sooner, and better protect you and your most sensitive data. Reducing Unplanned Updates As always, we treat any Chrome bug with a known in-the-wild exploit as a security incident of the highest priority and set about fixing the bug and getting a fix out to users as soon as possible. This has meant shipping the fix in an unscheduled update, so that you are protected imm | ★★ | ||
|
2023-08-04 13:50:22 | Pixel Binary Transparence: Sécurité vérifiable pour les périphériques Pixels Pixel Binary Transparency: verifiable security for Pixel devices (lien direct) |
Jay Hou, Software Engineer, TrustFabric (transparency.dev) Pixel Binary TransparencyWith Android powering billions of devices, we\'ve long put security first. There\'s the more visible security features you might interact with regularly, like spam and phishing protection, as well as less obvious integrated security features, like daily scans for malware. For example, Android Verified Boot strives to ensure all executed code comes from a trusted source, rather than from an attacker or corruption. And with attacks on software and mobile devices constantly evolving, we\'re continually strengthening these features and adding transparency into how Google protects users. This blog post peeks under the hood of Pixel Binary Transparency, a recent addition to Pixel security that puts you in control of checking if your Pixel is running a trusted installation of its operating system. Supply Chain Attacks & Binary TransparencyPixel Binary Transparency responds to a new wave of attacks targeting the software supply chain-that is, attacks on software while in transit to users. These attacks are on the rise in recent years, likely in part because of the enormous impact they can have. In recent years, tens of thousands of software users from Fortune 500 companies to branches of the US government have been affected by supply chain attacks that targeted the systems that create software to install a backdoor into the code, allowing attackers to access and steal customer data. | Spam | ★★ | |
|
2023-07-27 12:01:55 | Les hauts et les bas de 0 jours: une année en revue des 0 jours exploités dans le monde en 2022 The Ups and Downs of 0-days: A Year in Review of 0-days Exploited In-the-Wild in 2022 (lien direct) |
Maddie Stone, Security Researcher, Threat Analysis Group (TAG)This is Google\'s fourth annual year-in-review of 0-days exploited in-the-wild [2021, 2020, 2019] and builds off of the mid-year 2022 review. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a whole, looking for trends, gaps, lessons learned, and successes. Executive Summary41 in-the-wild 0-days were detected and disclosed in 2022, the second-most ever recorded since we began tracking in mid-2014, but down from the 69 detected in 2021. Although a 40% drop might seem like a clear-cut win for improving security, the reality is more complicated. Some of our key takeaways from 2022 include:N-days function like 0-days on Android due to long patching times. Across the Android ecosystem there were multiple cases where patches were not available to users for a significant time. Attackers didn\'t need 0-day exploits and instead were able to use n-days that functioned as 0-days. | Tool Vulnerability Threat Prediction Conference | ★★★ | |
|
2023-07-20 16:03:33 | Sécurité de la chaîne d'approvisionnement pour Go, partie 3: décalage à gauche Supply chain security for Go, Part 3: Shifting left (lien direct) |
Julie Qiu, Go Security & Reliability and Jonathan Metzman, Google Open Source Security TeamPreviously in our Supply chain security for Go series, we covered dependency and vulnerability management tools and how Go ensures package integrity and availability as part of the commitment to countering the rise in supply chain attacks in recent years. In this final installment, we\'ll discuss how “shift left” security can help make sure you have the security information you need, when you need it, to avoid unwelcome surprises. Shifting leftThe software development life cycle (SDLC) refers to the series of steps that a software project goes through, from planning all the way through operation. It\'s a cycle because once code has been released, the process continues and repeats through actions like coding new features, addressing bugs, and more.  Shifting left involves implementing security practices earlier in the SDLC. For example, consider scanning dependencies for known vulnerabilities; many organizations do this as part of continuous integration (CI) which ensures that code has passed security scans before it is released. However, if a vulnerability is first found during CI, significant time has already been invested building code upon an insecure dependency. Shifting left in this case mea |
Tool Vulnerability | ★★ | |
|
2023-07-20 12:00:23 | Un regard sur la culture de la révision de la sécurité de Chrome \\ A look at Chrome\\'s security review culture (lien direct) |
Posted by Alex Gough, Chrome Security Team Security reviewers must develop the confidence and skills to make fast, difficult decisions. A simplistic piece of advice to reviewers is “just be confident” but in reality that takes practice and experience. Confidence comes with time, and people are there to support each other as we learn. This post shares advice we give to people doing security reviews for Chrome. Security Review in Chrome Chrome has a lightweight launch process. Teams write requirements and design documents outlining why the feature should be built, how the feature will benefit users, and how the feature will be built. Developers write code behind a feature flag and must pass a Launch Review before turning it on. Teams think about security early-on and coordinate with the security team. Teams are responsible for the safety of their features and ensuring that the security team is able to say \'yes\' to its security review. Security review focuses on the design of a proposed feature, not its details and is distinct from code review. Chrome changes need approval from engineers familiar with the code being changed but not necessarily from security experts. It is not practical for security engineers to scrutinize every change. Instead we focus on the feature\'s architecture, and how it might affect people using Chrome. Reviewers function best in an open and supportive engineering culture. Security review is not an easy task – it applies security engineering insights in a social context that could become adversarial and fractious. Google, and Chrome, embody a security-centric engineering culture, where respectful disagreement is valued, where we learn from mistakes, where decisions can be revisited, and where developers see the security team as a partner that helps them ship features safely. Within the security team we support each other by encouraging questioning & learning, and provide mentorship and coaching to help reviewers enhance their reviewing skills. Learning security review Start by shadowing Start with some help. As a new reviewer, you may not feel you\'re 100% ready - don\'t let that put you off. The best way to learn is to observe and see what\'s involved before easing in to doing reviews on your own. Start by shadowing to get a feel for the process. Ask the person you are shadowing how they plan to approach the review, then look at the materials yourself. Concentrate on learning how to review rather than on the details of the thing you are reviewing. Don\'t get too involved but observe how the reviewer does things and ask them why. Next time try to co-review something - ask the feature team some questions and talk through your thoughts with the other reviewer. Let them make the final approval decision. Do this a few times and you\'ll be ready to be the main reviewer, and remember that you can always reach out for help and advice. Read enough to make a decision Read a lot, but know when to stop. Understand what the feature is doing, what\'s new, and what\'s built on existing, approved, mechanisms. Focus on the new things. If you need to educate yourself, skim older docs or code for context. It can help to look at related reviews for repeated issues and solutions. It is tempting to try to understand everything and at first you\'ll dig deeper than you need to. You\'ll get better at knowing when to stop after a few reviews. Treat existing, approved, features as building blocks that you don\'t need to fully understand, but might be useful to skim as background. | Threat | ★★ | |
|
2023-07-19 15:44:09 | Une étape importante vers la messagerie sécurisée et interopérable An important step towards secure and interoperable messaging (lien direct) |
Publié par Giles Hogben, directeur de l'ingénierie de la vie privée
La plupart des plateformes de messagerie de consommation modernes (y compris les messages Google) prennent en charge le cryptage de bout en bout, mais les utilisateurs sont aujourd'hui limités à communiquer avec des contacts qui utilisent la même plate-forme.C'est pourquoi Google soutient fortement les efforts de réglementation qui nécessitent l'interopérabilité pour les grandes plates-formes de messagerie de bout en bout.
Cependant, pour que l'interopérabilité réussisse dans la pratique, les réglementations doivent être combinées avec des normes ouvertes et vitées à l'industrie, en particulier dans le domaine de la vie privée, de la sécurité et du cryptage de bout en bout.Sans normalisation robuste, le résultat sera un spaghetti du middleware ad hoc qui pourrait réduire les normes de sécurité pour répondre au plus faible dénominateur commun et augmenter les coûts de mise en œuvre, en particulier pour les petits fournisseurs.Le manque de normalisation rendrait également les fonctionnalités avancées telles que la messagerie de groupe cryptée de bout en bout impossible dans la pratique & # 8211;Les messages de groupe devraient être cryptés et livrés plusieurs fois pour répondre à chaque protocole différent.
Avec la publication récente de la spécification de la sécurité de la couche de messagerie IETF (MLS) RFC 9420, les utilisateurs de messagerie peuvent attendre cette réalité.Pour la première fois, MLS permet l'interopérabilité pratique entre les services et les plates-formes, passant à des groupes de milliers d'utilisateurs multi-appareils.Il est également suffisamment flexible pour permettre aux fournisseurs de traiter les menaces émergentes pour la confidentialité et la sécurité des utilisateurs, tels que l'informatique quantique.
En garantissant une barre de sécurité et de confidentialité uniformément à laquelle les utilisateurs peuvent avoir confiance, MLS libérera un énorme domaine de nouvelles opportunités pour les utilisateurs et les développeurs de services de messagerie interopérables qui l'adoptent.C'est pourquoi nous avons l'intention de créer des MLS dans des messages Google et de prendre en charge son large déploiement à travers l'industrie en s'approvisionnement ouvert dans notre implémentation dans la base de code Android.
Posted by Giles Hogben, Privacy Engineering Director Most modern consumer messaging platforms (including Google Messages) support end-to-end encryption, but users today are limited to communicating with contacts who use the same platform. This is why Google is strongly supportive of regulatory efforts that require interoperability for large end-to-end messaging platforms. For interoperability to succeed in practice, however, regulations must be combined with open, industry-vetted, standards, particularly in the area of privacy, security, and end-to-end encryption. Without robust standardization, the result will be a spaghetti of ad hoc middleware that could lower security standards to cater for the lowest common denominator and raise implementation costs, particularly for smaller providers. Lack of standardization would also make advanced features such as end-to-end encrypted group messaging impossible in practice – group messages would have to be encrypted and delivered multiple times to cater for every different protocol. With the recent publication of the IETF\'s Message Layer Security (MLS) specification RFC 9420, messaging users can look forward to this reality. For the first time, MLS enables practical interoperability across services and platforms, scaling to groups of thousands of multi-device users. It is also flexible enough to allow providers to address emerging threats to user privacy and security, such as quantum computing. By ensuring a uniformly high security and p |
General Information | ★★★ | |
|
2023-06-29 18:11:49 | Cryptage côté client Gmail: une plongée profonde Gmail client-side encryption: A deep dive (lien direct) |
Nicolas Lidzborski, Principal Engineer and Jaishankar Sundararaman, Sr. Director of Engineering, Google WorkspaceIn February, we expanded Google Workspace client-side encryption (CSE) capabilities to include Gmail and Calendar in addition to Drive, Docs, Slides, Sheets, and Meet.CSE in Gmail was designed to provide commercial and public sector organizations an additional layer of confidentiality and data integrity protection beyond the existing encryption offered by default in Workspace. When CSE is enabled, email messages are protected using encryption keys that are fully under the customer\'s control. The data is encrypted on the client device before it\'s sent to Google servers that do not have access to the encryption keys, which means the data is indecipherable to us–we have no technical ability to access it. The entire process happens in the browser on the client device, without the need to install desktop applications or browser extensions, which means that users get the same intuitive productivity and collaboration experiences that they enjoy with Gmail today. Let\'s take a deeper look into how it works.How we built Client-side Encryption for WorkspaceWe invented and designed a new service called, Key Access Control List Service (KACLS), that is used across all essential Workspace applications. Then, we worked directly with customers and partners to make it secure, reliable, and simple to deploy. KACLS performs cryptographic operations with encryption keys after validating end-user authentication and authorization. It runs in a customer\'s controlled environment and provides the key management API called by the CSE- | Conference | ★★★ | |
|
2023-06-23 12:03:59 | Sécurité de la chaîne d'approvisionnement pour GO, partie 2: dépendances compromises Supply chain security for Go, Part 2: Compromised dependencies (lien direct) |
Julie Qiu, Go Security & Reliability, and Roger Ng, Google Open Source Security Team“Secure your dependencies”-it\'s the new supply chain mantra. With attacks targeting software supply chains sharply rising, open source developers need to monitor and judge the risks of the projects they rely on. Our previous installment of the Supply chain security for Go series shared the ecosystem tools available to Go developers to manage their dependencies and vulnerabilities. This second installment describes the ways that Go helps you trust the integrity of a Go package. Go has built-in protections against three major ways packages can be compromised before reaching you: A new, malicious version of your dependency is publishedA package is withdrawn from the ecosystemA malicious file is substituted for a currently used version of your dependencyIn this blog post we look at real-world scenarios of each situation and show how Go helps protect you from similar attac | ★★ | ||
|
2023-06-22 12:05:42 | Google Cloud attribue 313 337 $ en 2022 Prix VRP Google Cloud Awards $313,337 in 2022 VRP Prizes (lien direct) |
Anthony Weems, Information Security Engineer2022 was a successful year for Google\'s Vulnerability Reward Programs (VRPs), with over 2,900 security issues identified and fixed, and over $12 million in bounty rewards awarded to researchers. A significant amount of these vulnerability reports helped improve the security of Google Cloud products, which in turn helps improve security for our users, customers, and the Internet at large.We first announced the Google Cloud VRP Prize in 2019 to encourage security researchers to focus on the security of Google Cloud and to incentivize sharing knowledge on Cloud vulnerability research with the world. This year, we were excited to see an increase in collaboration between researchers, which often led to more detailed and complex vulnerability reports. After careful evaluation of the submissions, today we are excited to announce the winners of the 2022 Google Cloud VRP Prize.2022 Google Cloud VRP Prize Winners1st Prize - $133,337: Yuval Avrahami for the report and write-up Privilege escalations in GKE Autopilot. Yuval\'s excellent write-up describes several attack paths that would allow an attacker with permission to create pods in an Autopilot cluster to escalate privileges and compromise the underlying node VMs. While thes | Vulnerability Cloud | Uber | ★★ |
|
2023-06-20 11:58:57 | Protégez et gérez les extensions du navigateur à l'aide de la gestion du cloud Chrome Browser Protect and manage browser extensions using Chrome Browser Cloud Management (lien direct) |
Posted by Anuj Goyal, Product Manager, Chrome Browser
Browser extensions, while offering valuable functionalities, can seem risky to organizations. One major concern is the potential for security vulnerabilities. Poorly designed or malicious extensions could compromise data integrity and expose sensitive information to unauthorized access. Moreover, certain extensions may introduce performance issues or conflicts with other software, leading to system instability. Therefore, many organizations find it crucial to have visibility into the usage of extensions and the ability to control them. Chrome browser offers these extension management capabilities and reporting via Chrome Browser Cloud Management. In this blog post, we will walk you through how to utilize these features to keep your data and users safe.
Visibility into Extensions being used in your environment
Having visibility into what and how extensions are being used enables IT and security teams to assess potential security implications, ensure compliance with organizational policies, and mitigate potential risks. There are three ways you can get critical information about extensions in your organization:1. App and extension usage reportingOrganizations can gain visibility into every Chrome extension that is installed across an enterprise\'s fleet in Chrome App and Extension Usage Reporting.2. Extension Risk AssessmentCRXcavator and Spin.AI Risk Assessment are tools used to assess the risks of browser extensions and minimize the risks associated with them. We are making extension scores via these two platforms available directly in Chrome Browser Cloud Management, so security teams can have an at-a-glance view of risk scores of the extensions being used in their browser environment.
 3. Extension event reportingExtension installs events are now available to alert IT and security teams of new extension usage in their environment.Organizations can send critical browser security events to their chosen solution providers, such as Splunk, Crowdstrike, Palo Alto Networks, and Google solutions, including Chronicle, Cloud PubSub, and Google Workspace, for further analysis. You can also view the event logs directly in Chrome Browser Cloud Management. |
Cloud | ★★★ | |
|
2023-06-16 13:11:38 | Apporter la transparence à l'informatique confidentielle avec SLSA Bringing Transparency to Confidential Computing with SLSA (lien direct) |
Asra Ali, Razieh Behjati, Tiziano Santoro, Software EngineersEvery day, personal data, such as location information, images, or text queries are passed between your device and remote, cloud-based services. Your data is encrypted when in transit and at rest, but as potential attack vectors grow more sophisticated, data must also be protected during use by the service, especially for software systems that handle personally identifiable user data.Toward this goal, Google\'s Project Oak is a research effort that relies on the confidential computing paradigm to build an infrastructure for processing sensitive user data in a secure and privacy-preserving way: we ensure data is protected during transit, at rest, and while in use. As an assurance that the user data is in fact protected, we\'ve open sourced Project Oak code, and have introduced a transparent release process to provide publicly inspectable evidence that the application was built from that source code. This blog post introduces Oak\'s transparent release process, which relies on the SLSA framework to generate cryptographic proof of the origin of Oak\'s confidential computing stack, and together with Oak\'s remote attestation process, allows users to cryptographically verify that their personal data was processed by a trustworthy application in a secure environment. | Tool | ★★ | |
|
2023-06-14 11:59:49 | Apprentissage de KCTF VRP \\'s 42 Linux Neule exploite les soumissions Learnings from kCTF VRP\\'s 42 Linux kernel exploits submissions (lien direct) |
Tamás Koczka, Security EngineerIn 2020, we integrated kCTF into Google\'s Vulnerability Rewards Program (VRP) to support researchers evaluating the security of Google Kubernetes Engine (GKE) and the underlying Linux kernel. As the Linux kernel is a key component not just for Google, but for the Internet, we started heavily investing in this area. We extended the VRP\'s scope and maximum reward in 2021 (to $50k), then again in February 2022 (to $91k), and finally in August 2022 (to $133k). In 2022, we also summarized our learnings to date in our cookbook, and introduced our experimental mitigations for the most common exploitation techniques.In this post, we\'d like to share our learnings and statistics about the latest Linux kernel exploit submissions, how effective our | Vulnerability | Uber | ★★ |
|
2023-06-01 11:59:52 | Annonce du bonus d'exploitation en pleine chaîne du navigateur Chrome Announcing the Chrome Browser Full Chain Exploit Bonus (lien direct) |
Amy Ressler, Chrome Security Team au nom du Chrome VRP Depuis 13 ans, un pilier clé de l'écosystème de sécurité chromée a inclus des chercheurs en sécurité à trouver des vulnérabilités de sécurité dans Chrome Browser et à nous les signaler, à travers le Programme de récompenses de vulnérabilité Chrome . À partir d'aujourd'hui et jusqu'au 1er décembre 2023, le premier rapport de bogue de sécurité que nous recevons avec un exploit fonctionnel de la chaîne complète, résultant en une évasion chromée de sable, est éligible à triple le montant de la récompense complet .Votre exploit en pleine chaîne pourrait entraîner une récompense pouvant atteindre 180 000 $ (potentiellement plus avec d'autres bonus). Toutes les chaînes complètes ultérieures soumises pendant cette période sont éligibles pour doubler le montant de récompense complet ! Nous avons historiquement mis une prime sur les rapports avec les exploits & # 8211;«Des rapports de haute qualité avec un exploit fonctionnel» est le niveau le plus élevé de montants de récompense dans notre programme de récompenses de vulnérabilité.Au fil des ans, le modèle de menace de Chrome Browser a évolué à mesure que les fonctionnalités ont mûri et de nouvelles fonctionnalités et de nouvelles atténuations, tels a miracleptr , ont été introduits.Compte tenu de ces évolutions, nous sommes toujours intéressés par les explorations d'approches nouvelles et nouvelles pour exploiter pleinement le navigateur Chrome et nous voulons offrir des opportunités pour mieux inciter ce type de recherche.Ces exploits nous fournissent un aperçu précieux des vecteurs d'attaque potentiels pour exploiter Chrome et nous permettent d'identifier des stratégies pour un meilleur durcissement des caractéristiques et des idées de chrome spécifiques pour de futures stratégies d'atténuation à grande échelle. Les détails complets de cette opportunité de bonus sont disponibles sur le Chrome VRP Rules and Rewards page .Le résumé est le suivant: Les rapports de bogues peuvent être soumis à l'avance pendant que le développement de l'exploitation se poursuit au cours de cette fenêtre de 180 jours.Les exploits fonctionnels doivent être soumis à Chrome à la fin de la fenêtre de 180 jours pour être éligible à la triple ou double récompense. Le premier exploit fonctionnel de la chaîne complète que nous recevons est éligible au triple de récompense. L'exploit en chaîne complète doit entraîner une évasion de bac à sable de navigateur Chrome, avec une démonstration de contrôle / exécution de code de l'attaquant en dehors du bac à sable. L'exploitation doit pouvoir être effectuée à distance et aucune dépendance ou très limitée à l'interaction utilisateur. L'exploit doit avoir été fonctionnel dans un canal de libération actif de Chrome (Dev, Beta, stable, étendu stable) au moment des rapports initiaux des bogues dans cette chaîne.Veuillez ne pas soumettre des exploits développés à partir de bogues de sécurité divulgués publiquement ou d'autres artefacts dans les anciennes versions passées de Chrome. Comme cela est conforme à notre politique générale de récompenses, si l'exploit permet l'exécution du code distant (RCE) dans le navigateur ou un autre processus hautement privilégié, tel que le processus de réseau ou de GPU, pour entraîner une évasion de bac à sable sans avoir besoin d'une première étapeBug, le montant de récompense pour le rendu «rapport de haute qualité avec exploit fonctionnel» serait accordé et inclus dans le calcul du total de récompense de bonus. Sur la base de notre | Vulnerability Threat | ★★★ | |
|
2023-05-31 12:00:25 | Ajout d'actions de correction de la gestion du nuage de navigateur Chrome dans Splunk en utilisant des actions d'alerte Adding Chrome Browser Cloud Management remediation actions in Splunk using Alert Actions (lien direct) |
Posted by Ashish Pujari, Chrome Security Team
Introduction
Chrome is trusted by millions of business users as a secure enterprise browser. Organizations can use Chrome Browser Cloud Management to help manage Chrome browsers more effectively. As an admin, they can use the Google Admin console to get Chrome to report critical security events to third-party service providers such as Splunk® to create custom enterprise security remediation workflows.
Security remediation is the process of responding to security events that have been triggered by a system or a user. Remediation can be done manually or automatically, and it is an important part of an enterprise security program.
Why is Automated Security Remediation Important?
When a security event is identified, it is imperative to respond as soon as possible to prevent data exfiltration and to prevent the attacker from gaining a foothold in the enterprise. Organizations with mature security processes utilize automated remediation to improve the security posture by reducing the time it takes to respond to security events. This allows the usually over burdened Security Operations Center (SOC) teams to avoid alert fatigue.
Automated Security Remediation using Chrome Browser Cloud Management and Splunk
Chrome integrates with Chrome Enterprise Recommended partners such as Splunk® using Chrome Enterprise Connectors to report security events such as malware transfer, unsafe site visits, password reuse. Other supported events can be found on our support page.
The Splunk integration with Chrome browser allows organizations to collect, analyze, and extract insights from security events. The extended security insights into managed browsers will enable SOC teams to perform better informed automated security remediations using Splunk® Alert Actions.
Splunk Alert Actions are a great capability for automating security remediation tasks. By creating alert actions, enterprises can automate the process of identifying, prioritizing, and remediating security threats.
In Splunk®, SOC teams can use alerts to monitor for and respond to specific Chrome Browser Cloud Management events. Alerts use a saved search to look for events in real time or on a schedule and can trigger an Alert Action when search results meet specific conditions as outlined in the diagram below.
Use Case
If a user downloads a malicious file after bypassing a Chrome “Dangerous File” message their managed browser/managed CrOS device should be quarantined.
Prerequisites
Create a Chrome Browser Cloud Management account at no additional costs
|
Malware Cloud | ★★ |
To see everything:
Our RSS (filtrered)
