This is the RSS 2.0 feed from www.secnews.physaphae.fr. IT's a simple agragated flow of multiple articles soruces. Liste of sources, can be found on www.secnews.physaphae.fr. 2024-05-16T22:30:53+00:00 www.secnews.physaphae.fr GoogleSec - Firm Security Blog theft protection features to help keep your device and data safe in the case of theft, we\'re also focusing increasingly on providing additional protections against mobile financial fraud and scams. Today, we\'re announcing more new fraud and scam protection features coming in Android 15 and Google Play services updates later this year to help better protect users around the world. We\'re also sharing new tools and policies to help developers build safer apps and keep their users safe. Google Play Protect live threat detection Google Play Protect now scans 200 billion Android apps daily, helping keep more than 3 billion users safe from malware. We are expanding Play Protect\'s on-device AI capabilities with Google Play Protect live threat detection to improve fraud and abuse detection against apps that try to cloak their actions. With live threat detection, Google Play Protect\'s on-device AI will analyze additional behavioral signals related to the use of sensitive permissions and interactions with other apps and services. If suspicious behavior is discovered, Google Play Protect can send the app to Google for additional review and then warn users or disable the app if malicious behavior is confirmed. The detection of suspicious behavior is done on device in a privacy preserving way through Private Compute Core, which allows us to protect users without collecting data. Google Pixel, Honor, Lenovo, Nothing, OnePlus, Oppo, Sharp, Transsion, and other manufacturers are deploying live threat detection later this year. Stronger protections against fraud and scams We\'re also bringing additional protections to fight fraud and scams in Android 15 with two key enhancements to safeguard your information and privacy from bad apps: Protecting One-time Passwords from Malware: With the exception of a few types of apps, such as wearable companion apps, one-time passwords are now hidden from notifications, closing a common attack vector for fraud and spyware. Expanded Restricted Settings: To help protect more sensitive permissions that are commonly abused by fraudsters, we\'re expanding Android 13\'s restricted settings, which require additional user approval to enable permissions when installing an app from an Internet-sideloading source (web browsers, messaging apps or file managers). We are continuing to develop new, AI-powered protections,]]> 2024-05-15T12:59:21+00:00 http://security.googleblog.com/2024/05/io-2024-whats-new-in-android-security.html www.secnews.physaphae.fr/article.php?IdArticle=8500367 False Malware,Tool,Threat,Mobile,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog >>>>>>>>>>>>>>>>>> ... Google et Apple ont travaillé ensemble pour créer une spécification de l'industrie & # 8211; détection des trackers d'emplacement indésirables & # 8211;Pour les périphériques de suivi Bluetooth, cela permet d'alerter les utilisateurs à travers Android et iOS si un tel appareil est sans le savoir utilisé pour les suivre.Cela aidera à atténuer l'utilisation abusive des appareils conçus pour aider à suivre les effets personnels.Google lance désormais cette capacité sur les appareils Android 6.0+, et aujourd'hui Apple implémente cette capacité dans iOS 17.5. Avec cette nouvelle capacité, les utilisateurs d'Android obtiendront désormais une alerte «Tracker Traveling With You» sur leur appareil si un dispositif de suivi Bluetooth inconnu se déplace avec eux au fil du temps, quelle que soit la plate-forme avec laquelle l'appareil est associé. Si un utilisateur obtient une telle alerte sur son périphérique Android, cela signifie que AirTag de quelqu'un d'autre, trouvez ma balise de tracker compatible en réseau de périphérique, ou une autre Bluetooth Tracker compatible avec des spécifications de l'industrie se déplace avec eux.Les utilisateurs d'Android peuvent afficher l'identifiant du tracker \\, que le tracker joue un son pour aider à le localiser et à accéder aux instructions pour le désactiver.Les fabricants d'étiquettes Bluetooth, notamment Chipolo, Eufy, Jio, Motorola et Pebblebee, ont engagé que les futures étiquettes seront compatibles. Google \\ est que mon appareil est sécurisé par défaut et privé par conception. protection des utilisateurs multicouches , y compris le premier de sonProtections de sécurité avant la sécurité, aidez à atténuer les risques potentiels pour la confidentialité et la sécurité des utilisateurs tout en permettant aux utilisateurs de localiser et de récupérer efficacement les appareils perdus.Cette collaboration multiplateforme - une industrie d'abord, impliquant des contributions communautaires et de l'industrie - offre des instructions et les meilleures pratiques pour les fabricants, s'ils choisissent de créer des capacités d'alerte de suivi indésirables dans leurs produits.Google et Apple continueront de travailler avec les Force de travail d'ingénierie Internet via le groupe de travail des trackers de localisation indésirable pour développer le fonctionnaireNorme pour cette technologie.

---

]]> 2024-05-13T13:03:52+00:00 http://security.googleblog.com/2024/05/google-and-apple-deliver-support-for.html www.secnews.physaphae.fr/article.php?IdArticle=8499035 False Mobile None 3.0000000000000000 GoogleSec - Firm Security Blog Google launched passkey support for Google Accounts. Passkeys are a new industry standard that give users an easy, highly secure way to sign-in to apps and websites. Today, we announced that passkeys have been used to authenticate users more than 1 billion times across over 400 million Google Accounts.As more users encounter passkeys, we\'re often asked questions about how they relate to security keys, how Google Workspace administrators can configure passkeys for the user accounts that they manage, and how they relate to the Advanced Protection Program (APP). This post will seek to clarify these topics.Passkeys and security keysPasskeys are an evolution of security keys, meaning users get the same security benefits, but with a much simplified experience. Passkeys can be used in the Google Account sign-in process in many of the same ways that security keys have been used in the past - in fact, you can now choose to store your passkey on your security key. This provides users with three key benefits:Stronger security. Users typically authenticate with passkeys by entering their device\'s screen lock PIN, or using a ]]> 2024-05-02T07:59:51+00:00 http://security.googleblog.com/2024/05/passkeys-on-your-phone-computer-and-security-keys.html www.secnews.physaphae.fr/article.php?IdArticle=8493534 False None None 3.0000000000000000 GoogleSec - Firm Security Blog dbsc Cela aidera à perturber l'industrie du vol de cookies car l'exfiltration de ces cookies n'aura plus de valeur. Lorsqu'il n'est pas possible d'éviter le vol d'identification et de cookies par malware, la prochaine meilleure chose est de rendre l'attaque plus observable par antivirus, d'agents de détection de terminaux ou d'administrateurs d'entreprise avec des outils d'analyse de journaux de base. Ce blog décrit un ensemble de signaux à utiliser par les administrateurs système ou les agents de détection de point de terminaison qui devraient signaler de manière fiable tout accès aux données protégées du navigateur d'une autre application sur le système.En augmentant la probabilité d'une attaque détectée, cela modifie le calcul pour les attaquants qui pourraient avoir un fort désir de rester furtif et pourraient les amener à repenser ces types d'attaques contre nos utilisateurs. arrière-plan Les navigateurs basés sur le chrome sur Windows utilisent le DPAPI (API de protection des données) pour sécuriser les secrets locaux tels que les cookies, le mot de passe, etc.La protection DPAPI est basée sur une clé dérivée des informations d'identification de connexion de l'utilisateur et est conçue pour se protéger contre l'accès non autorisé aux secrets des autres utilisateurs du système ou lorsque le système est éteint.Étant donné que le secret DPAPI est lié à l'utilisateur connecté, il ne peut pas protéger contre les attaques de logiciels malveillants locaux - l'exécution de logiciels malveillants en tant qu'utilisateur ou à un niveau de privilège plus élevé peut simplement appeler les mêmes API que le navigateur pour obtenir le secret DPAPI. Depuis 2013, Chromium applique l'indicateur CryptProtect_Audit aux appels DPAPI pour demander qu'un journal d'audit soit généré lorsque le décryptage se produit, ainsi que le marquage des données en tant que détenue par le navigateur.Parce que tout le stockage de données crypté de Chromium \\ est soutenu par une clé sécurisée DPAPI, toute application qui souhaite décrypter ces données, y compris les logiciels malveillants, devrait toujours générer de manière fiable un journal d'événements clairement observable, qui peut être utilisé pour détecter ces typesd'attaques. Il y a trois étapes principales impliquées dans le profit de ce journal: Activer la connexion sur l'ordinateur exécutant Google Chrome, ou tout autre navigateur basé sur le chrome. Exporter les journaux des événements vers votre système backend. Créer une logique de détection pour détecter le vol. Ce blog montrera également comment la journalisation fonctionne dans la pratique en la testant contre un voleur de mot de passe Python. Étape 1: Activer la connexion sur le système Les événements DPAPI sont connectés à deux endroits du système.Premièrement, il y a le 4693 Événement qui peut être connecté au journal de sécurité.Cet événement peut être activé en activant "Audit l'activité DPAPI" et les étapes pour ce faire sont d]]> 2024-04-30T12:14:48+00:00 http://security.googleblog.com/2024/04/detecting-browser-data-theft-using.html www.secnews.physaphae.fr/article.php?IdArticle=8493535 False Malware,Tool,Threat None 2.0000000000000000 GoogleSec - Firm Security Blog 1 in part thanks to our investment in new and improved security features, policy updates, and advanced machine learning and app review processes. We have also strengthened our developer onboarding and review processes, requiring more identity information when developers first establish their Play accounts. Together with investments in our review tooling and processes, we identified bad actors and fraud rings more effectively and banned 333K bad accounts from Play for violations like confirmed malware and repeated severe policy violations. Additionally, almost 200K app submissions were rejected or remediated to ensure proper use of sensitive permissions such as background location or SMS access. To help safeguard user privacy at scale, we partnered with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over 31 SDKs impacting 790K+ apps. We also significantly expanded the Google Play SDK Index, which now covers the SDKs used in almost 6 million apps across the Android ecosystem. This valuable resource helps developers make better SDK choices, boosts app quality and minimizes integration risks. Protecting the Android Ecosystem Building on our success with the App Defense Alliance (ADA), we partnered with Microsoft and Meta as steering committee members in the newly restructured ADA under the Joint Development Foundation, part of the Linux Foundation family. The Alliance will support industry-wide adoption of app security best practices and guidelines, as well as countermeasures against emerging security risks. Additionally, we announced new Play Store transparency labeling to highlight VPN apps that have completed an independent security review through App Defense Alliance\'s Mobile App Security Assessment (MASA). 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. This helps users see at-a-glance that a developer has prioritized security and privacy best practices and is committed to user safety. ]]> 2024-04-29T11:59:47+00:00 http://security.googleblog.com/2024/04/how-we-fought-bad-apps-and-bad-actors-in-2023.html www.secnews.physaphae.fr/article.php?IdArticle=8493536 False Malware,Tool,Threat,Mobile None 3.0000000000000000 GoogleSec - Firm Security Blog IntroductionAs security professionals, we\'re constantly looking for ways to reduce risk and improve our workflow\'s efficiency. We\'ve made great strides in using AI to identify malicious content, block threats, and discover and fix vulnerabilities. We also published the Secure AI Framework (SAIF), a conceptual framework for secure AI systems to ensure we are deploying AI in a responsible manner. Today we are highlighting another way we use generative AI to help the defenders gain the advantage: Leveraging LLMs (Large Language Model) to speed-up our security and privacy incidents workflows.]]> 2024-04-26T18:33:10+00:00 http://security.googleblog.com/2024/04/accelerating-incident-response-using.html www.secnews.physaphae.fr/article.php?IdArticle=8493537 False Tool,Threat,Industrial,Cloud None 3.0000000000000000 GoogleSec - Firm Security Blog The Reporting API is an emerging web standard that provides a generic reporting mechanism for issues occurring on the browsers visiting your production website. The reports you receive detail issues such as security violations or soon-to-be-deprecated APIs, from users\' browsers from all over the world. Collecting reports is often as simple as specifying an endpoint URL in the HTTP header; the browser will automatically start forwarding reports covering the issues you are interested in to those endpoints. However, processing and analyzing these reports is not that simple. For example, you may receive a massive number of reports on your endpoint, and it is possible that not all of them will be helpful in identifying the underlying problem. In such circumstances, distilling and fixing issues can be quite a challenge. In this blog post, we\'ll share how the Google security team uses the Reporting API to detect potential issues and identify the actual problems causing them. We\'ll also introduce an open source solution, so you can easily replicate Google\'s approach to processing reports and acting on them. How does the Reporting API work? Some errors only occur in production, on users\' browsers to which you have no access. You won\'t see these errors locally or during development because there could be unexpected conditions real users, real networks, and real devices are in. With the Reporting API, you directly leverage the browser to monitor these errors: the browser catches these errors for you, generates an error report, and sends this report to an endpoint you\'ve specified. How reports are generated and sent. Errors you can monitor with the Reporting API include: Security violations: Content-Security-Policy (CSP), Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) Deprecated and soon-to-be-deprecated API calls Browser interventions Permissions policy And more For a full list of error types you can monitor, see use cases and report types. The Reporting API is activated and configured using HTTP response headers: you need to declare the endpoint(s) you want the browser to send reports to, and which error types you want to monitor. The browser then sends reports to your endpoint in POST requests whose payload is a list of reports. Example setup:#]]> 2024-04-23T13:15:47+00:00 http://security.googleblog.com/2024/04/uncovering-potential-threats-to-your.html www.secnews.physaphae.fr/article.php?IdArticle=8493538 False Malware,Tool,Vulnerability,Mobile,Cloud None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-04-18T13:40:42+00:00 http://security.googleblog.com/2024/04/prevent-generative-ai-data-leaks-with.html www.secnews.physaphae.fr/article.php?IdArticle=8486085 False Tool,Legislation None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-04-08T14:12:48+00:00 http://security.googleblog.com/2024/04/find-my-device-network-security-privacy-protections.html www.secnews.physaphae.fr/article.php?IdArticle=8486086 False Vulnerability,Threat,Mobile None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-03-28T18:16:18+00:00 http://security.googleblog.com/2024/03/address-sanitizer-for-bare-metal.html www.secnews.physaphae.fr/article.php?IdArticle=8477255 False Tool,Vulnerability,Mobile,Technical None 2.0000000000000000 GoogleSec - Firm Security Blog 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 “]]> 2024-03-28T14:29:57+00:00 http://security.googleblog.com/2024/03/google-public-dnss-approach-to-fight.html www.secnews.physaphae.fr/article.php?IdArticle=8477254 False Technical None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-03-14T12:01:32+00:00 http://security.googleblog.com/2024/03/blog-post.html www.secnews.physaphae.fr/article.php?IdArticle=8469136 False Malware,Mobile,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-03-12T11:59:14+00:00 http://security.googleblog.com/2024/03/vulnerability-reward-program-2023-year.html www.secnews.physaphae.fr/article.php?IdArticle=8469137 False Vulnerability,Threat,Mobile,Cloud,Conference None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-03-04T14:00:38+00:00 http://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html www.secnews.physaphae.fr/article.php?IdArticle=8458966 False Vulnerability,Mobile None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-02-13T20:14:39+00:00 http://security.googleblog.com/2024/02/piloting-new-ways-to-protect-Android-users-from financial-fraud.html www.secnews.physaphae.fr/article.php?IdArticle=8451429 False Malware,Threat,Mobile None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-02-05T11:59:31+00:00 http://security.googleblog.com/2024/02/improving-interoperability-between-rust-and-c.html www.secnews.physaphae.fr/article.php?IdArticle=8446993 False Tool,Vulnerability,Mobile None 3.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2024-02-01T13:40:22+00:00 http://security.googleblog.com/2024/02/un-cybercrime-treaty-could-endanger-web.html www.secnews.physaphae.fr/article.php?IdArticle=8445686 False Threat None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-01-31T13:07:18+00:00 http://security.googleblog.com/2024/01/scaling-security-with-ai-from-detection.html www.secnews.physaphae.fr/article.php?IdArticle=8445278 False Vulnerability,Patching,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-01-30T12:00:18+00:00 http://security.googleblog.com/2024/01/upgrade-to-passkeys-on-pixel-with-google-password-manager.html www.secnews.physaphae.fr/article.php?IdArticle=8444905 False Mobile Uber 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2024-01-11T14:18:14+00:00 http://security.googleblog.com/2024/01/miracleptr-protecting-users-from-use.html www.secnews.physaphae.fr/article.php?IdArticle=8440961 False Tool,Vulnerability,Threat,Mobile None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-12-12T12:00:09+00:00 http://security.googleblog.com/2023/12/hardening-cellular-basebands-in-android.html www.secnews.physaphae.fr/article.php?IdArticle=8421613 False Tool,Vulnerability,Threat,Mobile,Prediction,Conference None 3.0000000000000000 GoogleSec - Firm Security Blog 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 RETVecFigure 1. RETVec-based Gmail Spam filter improvements.]]> 2023-11-29T12:00:03+00:00 http://security.googleblog.com/2023/11/improving-text-classification.html www.secnews.physaphae.fr/article.php?IdArticle=8418787 False Spam,Mobile None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-11-20T11:49:31+00:00 http://security.googleblog.com/2023/11/two-years-later-baseline-that-drives-up.html www.secnews.physaphae.fr/article.php?IdArticle=8418788 False Vulnerability,Conference None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-11-08T09:03:58+00:00 http://security.googleblog.com/2023/11/evolving-app-defense-alliance.html www.secnews.physaphae.fr/article.php?IdArticle=8407899 False Malware,Threat,Mobile,Prediction None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-11-07T14:06:03+00:00 http://security.googleblog.com/2023/11/mte-promising-path-forward-for-memory.html www.secnews.physaphae.fr/article.php?IdArticle=8407434 False Vulnerability,Mobile None 3.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-11-03T16:37:53+00:00 http://security.googleblog.com/2023/11/qualified-certificates-with-qualified.html www.secnews.physaphae.fr/article.php?IdArticle=8405885 False Legislation None 2.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-11-02T12:00:24+00:00 http://security.googleblog.com/2023/11/more-ways-for-users-to-identify.html www.secnews.physaphae.fr/article.php?IdArticle=8405886 False Tool,Vulnerability,Mobile,Technical None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-10-26T08:49:41+00:00 http://security.googleblog.com/2023/10/increasing-transparency-in-ai-security.html www.secnews.physaphae.fr/article.php?IdArticle=8400810 False Malware,Tool,Vulnerability,Threat,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-10-26T08:00:33+00:00 http://security.googleblog.com/2023/10/googles-reward-criteria-for-reporting.html www.secnews.physaphae.fr/article.php?IdArticle=8400811 False Tool,Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog 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-25T08:00:33+00:00 http://security.googleblog.com/2023/10/joint-industry-statement-of-support-for.html www.secnews.physaphae.fr/article.php?IdArticle=8400125 False None None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-10-18T12:00:27+00:00 http://security.googleblog.com/2023/10/enhanced-google-play-protect-real-time.html www.secnews.physaphae.fr/article.php?IdArticle=8398646 False Spam,Malware None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-10-10T15:39:40+00:00 http://security.googleblog.com/2023/10/scaling-beyondcorp-with-ai-assisted.html www.secnews.physaphae.fr/article.php?IdArticle=8393959 False Tool,Vulnerability None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-10-09T12:30:13+00:00 http://security.googleblog.com/2023/10/bare-metal-rust-in-android.html www.secnews.physaphae.fr/article.php?IdArticle=8393306 False Tool,Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog 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?]]> 2023-10-06T10:21:05+00:00 http://security.googleblog.com/2023/10/expanding-our-exploit-reward-program-to.html www.secnews.physaphae.fr/article.php?IdArticle=8392241 False Vulnerability,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-09-27T12:51:29+00:00 http://security.googleblog.com/2023/09/sms-security-privacy-gaps-make-it-clear.html www.secnews.physaphae.fr/article.php?IdArticle=8388447 False Vulnerability,Threat,Studies APT 41 3.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-09-21T12:00:57+00:00 http://security.googleblog.com/2023/09/scaling-rust-adoption-through-training.html www.secnews.physaphae.fr/article.php?IdArticle=8386349 False Tool None 2.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-09-15T14:11:38+00:00 http://security.googleblog.com/2023/09/capslock-what-is-your-code-really.html www.secnews.physaphae.fr/article.php?IdArticle=8383846 False Tool,Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-08-29T12:06:35+00:00 http://security.googleblog.com/2023/08/android-goes-all-in-on-fuzzing.html www.secnews.physaphae.fr/article.php?IdArticle=8376312 False Vulnerability,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-08-16T13:03:58+00:00 http://security.googleblog.com/2023/08/ai-powered-fuzzing-breaking-bug-hunting.html www.secnews.physaphae.fr/article.php?IdArticle=8370865 False Vulnerability,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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-15T17:57:56+00:00 http://security.googleblog.com/2023/08/toward-quantum-resilient-security-keys.html www.secnews.physaphae.fr/article.php?IdArticle=8370466 False None None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-08-10T12:01:36+00:00 http://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html www.secnews.physaphae.fr/article.php?IdArticle=8368444 False Tool None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-08-08T13:33:00+00:00 http://security.googleblog.com/2023/08/downfall-and-zenbleed-googlers-helping.html www.secnews.physaphae.fr/article.php?IdArticle=8367398 False Vulnerability,Prediction,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-08-08T11:59:13+00:00 http://security.googleblog.com/2023/08/android-14-introduces-first-of-its-kind.html www.secnews.physaphae.fr/article.php?IdArticle=8367399 False Malware,Tool,Threat,Conference None 3.0000000000000000 GoogleSec - Firm Security Blog 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-08T11:59:04+00:00 http://security.googleblog.com/2023/08/an-update-on-chrome-security-updates.html www.secnews.physaphae.fr/article.php?IdArticle=8367400 False None None 2.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-08-04T13:50:22+00:00 http://security.googleblog.com/2023/08/pixel-binary-transparency-verifiable.html www.secnews.physaphae.fr/article.php?IdArticle=8365763 False Spam None 2.0000000000000000 GoogleSec - Firm Security Blog 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.]]> 2023-07-27T12:01:55+00:00 http://security.googleblog.com/2023/07/the-ups-and-downs-of-0-days-year-in.html www.secnews.physaphae.fr/article.php?IdArticle=8362307 False Tool,Vulnerability,Threat,Prediction,Conference None 3.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-07-20T16:03:33+00:00 http://security.googleblog.com/2023/07/supply-chain-security-for-go-part-3.html www.secnews.physaphae.fr/article.php?IdArticle=8359415 False Tool,Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-07-20T12:00:23+00:00 http://security.googleblog.com/2023/07/a-look-at-chromes-security-review.html www.secnews.physaphae.fr/article.php?IdArticle=8359335 False Threat None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-07-19T15:44:09+00:00 http://security.googleblog.com/2023/07/an-important-step-towards-secure-and.html www.secnews.physaphae.fr/article.php?IdArticle=8358965 False General Information None 3.0000000000000000 GoogleSec - Firm Security Blog 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-]]> 2023-06-29T18:11:49+00:00 http://security.googleblog.com/2023/06/gmail-client-side-encryption-deep-dive.html www.secnews.physaphae.fr/article.php?IdArticle=8350827 False Conference None 3.0000000000000000 GoogleSec - Firm Security Blog 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-23T12:03:59+00:00 http://security.googleblog.com/2023/06/supply-chain-security-for-go-part-2.html www.secnews.physaphae.fr/article.php?IdArticle=8348577 False None None 2.0000000000000000 GoogleSec - Firm Security Blog 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]]> 2023-06-22T12:05:42+00:00 http://security.googleblog.com/2023/06/google-cloud-awards-313337-in-2022-vrp.html www.secnews.physaphae.fr/article.php?IdArticle=8348159 False Vulnerability,Cloud Uber 2.0000000000000000 GoogleSec - Firm Security Blog 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.]]> 2023-06-20T11:58:57+00:00 http://security.googleblog.com/2023/06/protect-and-manage-browser-extensions.html www.secnews.physaphae.fr/article.php?IdArticle=8347380 False Cloud None 3.0000000000000000 GoogleSec - Firm Security Blog 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. ]]> 2023-06-16T13:11:38+00:00 http://security.googleblog.com/2023/06/bringing-transparency-to-confidential.html www.secnews.physaphae.fr/article.php?IdArticle=8346271 False Tool None 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-06-14T11:59:49+00:00 http://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html www.secnews.physaphae.fr/article.php?IdArticle=8345378 False Vulnerability Uber 2.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-06-01T11:59:52+00:00 http://security.googleblog.com/2023/06/announcing-chrome-browser-full-chain.html www.secnews.physaphae.fr/article.php?IdArticle=8341245 False Vulnerability,Threat None 3.0000000000000000 GoogleSec - Firm Security Blog 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 ]]> 2023-05-31T12:00:25+00:00 http://security.googleblog.com/2023/05/adding-chrome-browser-cloud-management.html www.secnews.physaphae.fr/article.php?IdArticle=8340926 False Malware,Cloud None 2.0000000000000000 GoogleSec - Firm Security Blog g.co/ctf.Google CTF gives you a chance to challenge your skillz, show off your hacktastic abilities, and learn some new tricks along the way. It consists of a set of computer security puzzles (or challenges) involving reverse-engineering, memory corruption, cryptography, web technologies, and more. Use obscure security knowledge to find exploits through bugs and creative misuse. With each completed challenge your team will earn points and move up through the ranks. The top 8 teams will qualify for our Hackceler8 competition taking place in Tokyo later this year. Hackceler8 is our experimental esport-style hacking game, custom-made to mix CTF and speedrunning. In the competition]]> 2023-05-26T14:06:55+00:00 http://security.googleblog.com/2023/05/time-to-challenge-yourself-in-2023-google-ctf.html www.secnews.physaphae.fr/article.php?IdArticle=8339707 False None None 2.0000000000000000 GoogleSec - Firm Security Blog g.co/ctf.Google CTF gives you a chance to challenge your skillz, show off your hacktastic abilities, and learn some new tricks along the way. It consists of a set of computer security puzzles (or challenges) involving reverse-engineering, memory corruption, cryptography, web technologies, and more. Use obscure security knowledge to find exploits through bugs and creative misuse. With each completed challenge your team will earn points and move up through the ranks. The top 8 teams will qualify for our Hackceler8 competition taking place in Tokyo later this year. Hackceler8 is our experimental esport-style hacking game, custom-made to mix CTF and speedrunning. In the competition, teams need to find clever ways to abuse the game features to capture flags as quickly as possible. See the 2022 highlight reel to get a sense of what it\'s like. The prize pool for this year\'s event stands at more than $32,000!]]> 2023-05-26T12:02:28+00:00 http://security.googleblog.com/2023/05/time-to-challenge-yourself-in-2023.html www.secnews.physaphae.fr/article.php?IdArticle=8339668 False Conference None 4.0000000000000000 GoogleSec - Firm Security Blog Google Trust Services now offers our ACME API to all users with a Google Cloud account (referred to as “users” here), allowing them to automatically acquire and renew publicly-trusted TLS certificates for free. The ACME API has been available as a preview and over 200 million certificates have been issued already, offering the same compatibility as major Google services like google.com or youtube.com.]]> 2023-05-25T12:00:55+00:00 http://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html www.secnews.physaphae.fr/article.php?IdArticle=8339416 False Tool,Cloud None 3.0000000000000000 GoogleSec - Firm Security Blog Graph for Understanding Artifact Composition (GUAC). Introduced at Kubecon 2022 in October, GUAC targets a critical need in the software industry to understand the software supply chain. In collaboration with Kusari, Purdue University, Citi, and community members, we have incorporated feedback from our early testers to improve GUAC and make it more useful for security professionals. This improved version is now available as an API for you to start developing on top of, and integrating into, your systems.The need for GUACHigh-profile incidents such as Solarwinds, and the recent 3CX supply chain double-exposure, are evidence that supply chain attacks are getting more sophisticated. As highlighted by the ]]> 2023-05-24T12:49:28+00:00 http://security.googleblog.com/2023/05/announcing-launch-of-guac-v01.html www.secnews.physaphae.fr/article.php?IdArticle=8339090 False Tool,Vulnerability,Threat Yahoo 2.0000000000000000 GoogleSec - Firm Security Blog announced in September 2022. If you missed it, don\'t worry - we\'ll give you a quick summary below! Chrome Root Program: TL;DR Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes for its users are secure and private. Certificates are issued by trusted entities called “Certification Authorities” (CAs). The collection of digital certificates, CA systems, and other related online servicews is the foundation of HTTPS and is often referred to as the “Web PKI.” Before issuing a certificate to a website, the CA must verify that the certificate requestor legitimately controls the domain whose name will be represented in the certificate. This process is often referred to as “domain validation” and there are several methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value\'s presence. Typically, domain validation practices must conform with a set of security requirements described in both industry-wide and browser-specific policies, like the CA/Browser Forum “Baseline Requirements” and the Chrome Root Program policy. Upon connecting to a website, Chrome verifies that a recognized (i.e., trusted) CA issued its certificate, while also performing additional evaluations of the connection\'s security properties (e.g., validating data from Certificate Transparency logs). Once Chrome determines that the certificate is valid, Chrome can use it to establish an encrypted connection to the website. Encrypted connections prevent attackers from being able to intercept (i.e., eavesdrop) or modify communication. In security speak, this is known as confidentiality and integrity. The Chrome Root Program, led by members of the Chrome Security team, provides governance and security review to determine the set of CAs trusted by default in Chrome. This set of so-called "root certificates" is known at the Chrome Root Store. How does the Chrome Root Program keep users safe? The Chrome Root Program keeps users safe by ensuring the CAs Chrome trusts to validate domains are worthy of that trust. We do that by: administering policy and governance activities to manage the set of CAs trusted by default in Chrome, evaluating impact and corresponding security implications related to public security incident disclosures by participating CAs, and leading positive change to make the ecosystem more resilient. Policy and Governance The Chrome Root Program policy defines the minimum requirements a CA owner must meet for inclusion in the Chrome Root Store. It incorporates the industry-wide CA/Browser Forum Baseline Requirements and further adds security controls to improve Chrome user security. The CA ]]> 2023-05-23T12:01:36+00:00 http://security.googleblog.com/2023/05/how-chrome-root-program-keeps-users-safe.html www.secnews.physaphae.fr/article.php?IdArticle=8338783 False None None 2.0000000000000000 GoogleSec - Firm Security Blog Page des règles publiques . De plus, à partir du 15 mars 2023, Android n'attribuera plus de vulnérabilités et d'expositions courantes (CVE) à la plupart des problèmes de gravité modérés.Le CVE continuera d'être affecté à des vulnérabilités critiques et à forte gravité. Nous pensons que l'incitation aux chercheurs à fournir des rapports de haute qualité profitera à la fois à la communauté de sécurité plus large et à notre]]> 2023-05-17T11:59:38+00:00 http://security.googleblog.com/2023/05/new-android-google-device-VRP.html www.secnews.physaphae.fr/article.php?IdArticle=8337421 False Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog ISCE\'s Search-Based and Fuzz Testing (SBFT) Workshop. Our goal was to encourage the development of new fuzzing techniques, which can lead to the discovery of software vulnerabilities and ultimately a safer open source ecosystem. The competitors\' fuzzers were judged on code coverage and their ability to discover bugs: HasteFuzz took the $11,337 prize for code coveragePASTIS and AFLrustrust tied for bug discovery and split the $11,337 prizeCompetitors were evaluated using ]]> 2023-05-15T13:35:50+00:00 http://security.googleblog.com/2023/05/22k-awarded-to-sbft-23-fuzzing.html www.secnews.physaphae.fr/article.php?IdArticle=8336747 False Conference None 2.0000000000000000 GoogleSec - Firm Security Blog Buzzer, a new eBPF Fuzzing framework that aims to help hardening the Linux Kernel.What is eBPF and how does it verify safety?eBPF is a technology that allows developers and sysadmins to easily run programs in a privileged context, like an operating system kernel. Recently, its popularity has increased, with more products adopting it as, for example, a network filtering solution. At the same time, it has maintained its relevance in the security research community, since it provides a powerful attack surface into the operating system.While there are many solutions for fuzzing vulnerabilities in the Linux Kernel, they are not necessarily tailored to the unique features of eBPF. In particular, eBPF has many complex security rules that programs must follow to be considered valid and safe. These rules are enforced by a component of eBPF referred to as the "verifier". The correctness properties of the verifier implementation have proven difficult to understand by reading the source code alone. That\'s why our security team at Google decided to create a new fuzzer framework that aims to test the limits of the eBPF verifier through generating eBPF programs.The eBPF verifier\'s main goal is to make sure that a program satisfies a certain set of safety rules, for example: programs should not be able to write outside designated memory regions, certain arithmetic operations should be restricted on pointers, and so on. However, like all pieces of software, there can be holes in the logic of these checks. This could potentially cause unsafe behavior of an eBPF program and have security implications.]]> 2023-05-11T12:44:52+00:00 http://security.googleblog.com/2023/05/introducing-new-way-to-buzz-for-ebpf.html www.secnews.physaphae.fr/article.php?IdArticle=8335705 False None None 2.0000000000000000 GoogleSec - Firm Security Blog 1. Safe Browsing isn\'t just getting faster at warning users. We\'ve also been building in more intelligence, leveraging Google\'s advances in AI. Last year, Chrome browser on Android and desktop started utilizing a new image-based phishing detection machine learning model to visually inspect fake sites that try to pass themselves off as legitimate log-in pages. By leveraging a TensorFlow Lite model, we\'re able to find 3x more2 phishing sites compared to previous machine learning models and help warn you before you get tricked into signing in. This year, we\'re expanding the coverage of the model to detect hundreds of more phishing campaigns and leverage new ML technologies. This is just one example of how we use our AI expertise to keep your data safe. Last year, Android used AI to protect users from 100 billion suspected spam messages and calls.3 Passkeys helps move users beyond passwords For many, passwords are the primary protection for their online life. In reality, they are frustrating to create, remember and are easily hacked. But hackers can\'t phish a password that doesn\'t exist. Which is why we are excited to share another major step forward in our passwordless journey: Passkeys. ]]> 2023-05-10T14:59:36+00:00 http://security.googleblog.com/2023/05/io-2023-android-security-and-privacy.html.html www.secnews.physaphae.fr/article.php?IdArticle=8335428 False Spam,Malware,Tool None 3.0000000000000000 GoogleSec - Firm Security Blog Google announced its next step toward a passwordless future: passkeys. Passkeys are a new, passwordless authentication method that offer a convenient authentication experience for sites and apps, using just a fingerprint, face scan or other screen lock. They are designed to enhance online security for users. Because they are based on the public key cryptographic protocols that underpin security keys, they are resistant to phishing and other online attacks, making them more secure than SMS, app based one-time passwords and other forms of multi-factor authentication (MFA). And since passkeys are standardized, a single implementation enables a passwordless experience across browsers and operating systems. Passkeys can be used in two different ways: on the same device or from a different device. For example, if you need to sign in to a website on an Android device and you have a passkey stored on that same device, then using it only involves unlocking the phone. On the other hand, if you need to sign in to that website on the Chrome browser on your computer, you simply scan a QR code to connect the phone and computer to use the passkey.The technology behind the former (“same device passkey”) is not new: it was originally developed within the FIDO Alliance and first implemented by Google in August 2019 in select flows. Google and other FIDO members have been working together on enhancing the underlying technology of passkeys over the last few years to improve their usability and convenience. This technology behind passkeys allows users to log in to their account using any form of device-based user verification, such as biometrics or a PIN code. A credential is only registered once on a user\'s personal device, and then the device proves possession of the registered credential to the remote server by asking the user to use their device\'s screen lock. The user\'s biometric, or other screen lock data, is never sent to Google\'s servers - it stays securely stored on the device, and only cryptographic proof that the user has correctly provided it is sent to Google. Passkeys are also created and stored on your devices and are not sent to websites or apps. If you create a passkey on one device the Google Password Manager can make it available on your other devices that are signed into the same system account.Learn more on how passkey works under the hoo]]> 2023-05-05T12:00:43+00:00 http://security.googleblog.com/2023/05/making-authentication-faster-than-ever.html www.secnews.physaphae.fr/article.php?IdArticle=8333804 False None APT 38,APT 10,APT 15,Guam 2.0000000000000000 GoogleSec - Firm Security Blog Aspect and the Rules Authors Special Interest Group. In this post, we\'ll explain how rules_oci differs from its predecessor, rules_docker, and describe the benefits it offers for both container image security and the container community. Bazel and Distroless for supply chain securityGoogle\'s popular build and test tool, known as Bazel, is gaining fast adoption within enterprises thanks to its ability to scale to the largest codebases and handle builds in almost any language. Because Bazel manages and caches dependencies by their integrity hash, it is uniquely suited to make assurances about the supply chain based on the Trust-on-First-Use principle. One way Google uses Bazel is to build widely used Distroless base images for Docker. Distroless is a series of minimal base images which improve supply-chain security. They restrict what\'s in your runtime container to precisely what\'s necessary for your app, which is a best practice employed by Google and other tech companies that have used containers in production for many years. Using minimal base images reduces the burden of managing risks associated with security vulnerabilities, licensing, and governance issues in the supply chain for building applications.rules_oci vs rules_docker]]> 2023-05-05T11:02:09+00:00 http://security.googleblog.com/2023/05/introducing-rulesoci.html www.secnews.physaphae.fr/article.php?IdArticle=8333805 False None None 2.0000000000000000 GoogleSec - Firm Security Blog today, you can create and use passkeys on your personal Google Account. When you do, Google will not ask for your password or 2-Step Verification (2SV) when you sign in.Passkeys are a more convenient and safer alternative to passwords. They work on all major platforms and browsers, and allow users to sign in by unlocking their computer or mobile device with their fingerprint, face recognition or a local PIN.Using passwords puts a lot of responsibility on users. Choosing strong passwords and remembering them across various accounts can be hard. In addition, even the most savvy users are often misled into giving them up during phishing attempts. 2SV (2FA/MFA) helps, but again puts strain on the user with additional, unwanted friction and still doesn\'t fully protect against phishing attacks and targeted attacks like "SIM swaps" for SMS verification. Passkeys help address all these issues.Creating passkeys on your Google AccountWhen you add a passkey to your Google Account, we will start asking for it when you sign in or perform sensitive actions on your account. The passkey itself is stored on your local computer or mobile device, which will ask for your screen lock biometrics or PIN to confirm it\'s really you. Biometric data is never shared with Google or any other third party – the screen lock only unlocks the passkey locally.Unlike passwords, passkeys can only exist on your devices. They cannot be written down or accidentally given to a bad actor. When you use a passkey to sign]]> 2023-05-03T08:20:21+00:00 http://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html www.secnews.physaphae.fr/article.php?IdArticle=8333111 False None None 3.0000000000000000 GoogleSec - Firm Security Blog Location-tracking devices help users find personal items like their keys, purse, luggage, and more through crowdsourced finding networks. However, they can also be misused for unwanted tracking of individuals. Today Google and Apple jointly submitted a proposed industry specification to help combat the misuse of Bluetooth location-tracking devices for unwanted tracking. The first-of-its-kind specification will allow Bluetooth location-tracking devices to be compatible with unauthorized tracking detection and alerts across Android and iOS platforms. Samsung, Tile, Chipolo, eufy Security, and Pebblebee have expressed support for the draft specification, which offers best practices and instructions for manufacturers, should they choose to build these capabilities into their products.“Bluetooth trackers have created tremendous user benefits but also bring the potential of unwanted tracking, which requires industry-wide action to solve,” said Dave Burke, Google\'s vice president of Engineering for Android. “Android has an unwavering commitment to protecting users and will continue to develop strong safeguards and collaborate with the industry to help combat the misuse of Bluetooth tracking devices.” “Apple launched AirTag to give users the peace of mind knowing where to find their most important items,” said Ron Huang, Apple\'s vice president of Sensing and Connectivity. “We built AirTag and the Find My network with a set of proactive features to discourage unwanted tracking, a first in the industry, and we continue to make improvements to help ensure the technology is being used as intended. “This new industry specification builds upon the AirTag protections, and through collaboration with Google, results in a critical step forward to help combat unwanted tracking across iOS and Android.” In addition to incorporating feedback from device manufacturers, input from various safety and advocacy groups has been integrated into the development of the specification. “The National Network to End Domestic Violence has been advocating for universal standards to protect survivors – and all people – from the misuse of bluetooth tracking devices. This collaboration and the resulting standards are a significant step forward. NNEDV is encouraged by this progress,” said Erica Olsen, the National Network to End Domestic Violence\'s senior director of its Safety Net Project. “These new standards will minimize opportunities for abuse of this technology and decrease burdens on survivors in detecting unwanted trackers. We are grateful for these efforts and look forward to continuing to work together to address unwanted tracking and misuse.” “Today\'s release of a draft specification is a welcome step to confront harmful misuses of Bluetooth location trackers,” said Alexandra Reeve Givens, the Center for Democracy & Technology\'s president and CEO. “CDT continues to focus on ways to make these devices more detectable and reduce the likelihood that they will be used to track people. A key]]> 2023-05-02T09:01:05+00:00 http://security.googleblog.com/2023/05/google-and-apple-lead-initiative-for.html www.secnews.physaphae.fr/article.php?IdArticle=8332834 False None None 2.0000000000000000 GoogleSec - Firm Security Blog Annommé Ils travaillent avec Google sur un projet pilote pour établir une confirmation protégée en tant que norme d'interface programmable d'application courante.Dans un pilote prévu pour 2023, les clients bancaires en ligne UBS avec des appareils Pixel 6 ou 7 peuvent utiliser une confirmation protégée Android soutenue par Strongbox, un coffre-fort certifié avec protection d'attaque physique, pour confirmer les paiements et vérifier les achats en ligne grâce à une confirmation matérielle dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur conviction dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation dans leur confirmation de leur matériel dans leurUBS Access App. démontrant une utilisation réelle pour la confirmation de protection Android Nous avons travaillé en étroite collaboration avec UBS pour donner vie à ce pilote et nous assurer qu'ils peuvent le tester sur les appareils Google Pixel.La démonstration des cas d'utilisation du monde réel qui sont activés par la confirmation protégée par Android débloque la promesse de cette tech]]> 2023-04-28T11:59:39+00:00 http://security.googleblog.com/2023/04/secure-mobile-payment-transactions.html www.secnews.physaphae.fr/article.php?IdArticle=8331914 False None None 3.0000000000000000 GoogleSec - Firm Security Blog preventing over $2 billion in fraudulent and abusive transactions. We\'ve raised the bar for new developers to join the Play ecosystem with phone, email, and other identity verification methods, which contributed to a reduction in accounts used to publish violative apps. We continued to partner with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over one million apps on Google Play. With strengthened Android platform protections and policies, and developer outreach and education, we prevented about 500K submitted apps from unnecessarily accessing sensitive permissions over the past 3 years. Developer Support and Collaboration to Help Keep Apps Safe As the Android ecosystem expands, it\'s critical for us to work closely with the developer community to ensure they have the tools, knowledge, and support to build secure and trustworthy apps that respect user data security and privacy. In 2022, the App Security Improvements program helped developers fix ~500K security weaknesses affecting ~300K apps with a combined install base of approximately 250B installs. We also launched the Google Play SDK Index to help developers evaluate an SDK\'s reliability and safety and make informed decisions about whether an SDK is right for their business and their users. We will keep working closely with SDK providers to improve app and SDK safety, limit how user data is shared, and improve lines of communication with app developers. We also recently launched new features and resources to give developers a better policy experience. We\'ve expanded our Helpline pilot to give more developers direct policy phone support. And we piloted the Google Play Developer Community so more developers can discuss policy questions and exchange best practices on how to build ]]> 2023-04-27T11:01:43+00:00 http://security.googleblog.com/2023/04/how-we-fought-bad-apps-and-bad-actors.html www.secnews.physaphae.fr/article.php?IdArticle=8331577 False Malware,Prediction Uber 4.0000000000000000 GoogleSec - Firm Security Blog announced the release of SLSA v1.0, a framework that helps secure the software supply chain. Ten years of using an internal version of SLSA at Google has shown that it\'s crucial to warding off tampering and keeping software secure. It\'s especially gratifying to see SLSA reaching v1.0 as an open source project-contributors have come together to produce solutions that will benefit everyone. SLSA for safer supply chains Developers and organizations that adopt SLSA will be protecting themselves against a variety of supply chain attacks, which have continued rising since Google first donated SLSA to OpenSSF in 2021. In that time, the industry has also seen a U.S. Executive Order on Cybersecurity and the associated NIST Secure Software Development Framework (SSDF) to guide national standards for software used by the U.S. government, as well as the Network and Information Security (NIS2) Directive in the European Union. SLSA offers not only an onramp to meeting these standards, but also a way to prepare for a climate of increased scrutiny on software development practices. As organizations benefit from using SLSA, it\'s also up to them to shoulder part of the burden of spreading these benefits to open source projects. Many maintainers of the critical open source projects that underpin the internet are volunteers; they cannot be expected to do all the work when so many of the rewards of adopting SLSA roll out across the supply chain to benefit everyone. Supply chain security for all That\'s why beyond contributing to SLSA, we\'ve also been laying the foundation to integrate supply chain solutions directly into the ecosystems and platforms used to create open source projects. We\'re also directly supporting open source maintainers, who often cite lack of time or resources as limiting factors when making security improvements to their projects. Our Open Source Security Upstream Team consists of developers who spend 100% of their time contributing to critical open source projects to make security improvements. For open source developers who choose to adopt SLSA on their own, we\'ve funded the Secure Open Source Rewards Program, which pays developers directly for these types of security improvements. Currently, open source developers who want to secure their builds can use the free SLSA L3 GitHub Builder, which requires only a one-time adjustment to the traditional build process implemented through GitHub actions. There\'s also the SLSA Verifier tool for software consumers. Users of npm-or Node Package Manager, the world\'s largest software repository-can take advantage of their recently released beta SLSA integration, which streamlines the process of creating and verifying SLSA provenance through the npm command line interface. We\'re also supporting the integration of Sigstore into many major]]> 2023-04-26T11:00:21+00:00 http://security.googleblog.com/2023/04/celebrating-slsa-v10-securing-software.html www.secnews.physaphae.fr/article.php?IdArticle=8331269 False Tool,Patching None 2.0000000000000000 GoogleSec - Firm Security Blog 2023-04-24T12:00:03+00:00 http://security.googleblog.com/2023/04/google-authenticator-now-supports.html www.secnews.physaphae.fr/article.php?IdArticle=8330674 False None None 3.0000000000000000 GoogleSec - Firm Security Blog “sandbox domains”. The basic idea is that if your application\'s main domain is example.com, you could serve all untrusted content on exampleusercontent.com. Since these two domains are cross-site, any malicious content on exampleusercontent.com can\'t impact example.com. This approach can be used to safely serve all kinds of untrusted content including images, downloads, and HTML. While it may not seem like it is necessary to use this for images or downloads, doing so helps avoid risks from content sniffing, especially in legacy browsers. Sandbox domains are widely used across the industry and have worked well for a long time. But, they have two major downsides: Applications often need to restrict content access to a single user, which requires implementing authentication and authorization. Since sandbox domains purposefully do not share cookies with the main application domain, this is very difficult to do securely. To support authentication, sites either have to rely on capability URLs, or they have to set separate authentication cookies for the sandbox domain. This second method is especially problematic in the modern web where many browsers restrict cross-site cookies by default. While user content is isolated from the main site, it isn\'t isolated from other user content. This creates the risk of malicious user content attacking other data on the sandbox domain (e.g. via reading same-origin data). It is also worth noting that sandbox domains help mitigate phishing risks since resources are clearly segmented onto an isolated domain. Modern Solutions for Serving User Content Over time the web has evolved, and there are now easier, more secure ways to serve untrusted content. There are many different approaches here, so we will outline two solutions that are currently in wide use at Google. Approach 1: Serving Inactive User Content If a site only needs to serve inactive user content (i.e. content that is not HTML/JS, for example images and downloads), this can now be safely done without an isolated sandbox domain. There are two key steps: Always set the Content-Type header to a well-known MIME type that is supported by all browsers and guaranteed not to contain active content (when in doubt, application/octet-stream is a safe choice). In addition, always set the below response headers to ensure that the browser fully isolates the response. ]]> 2023-04-18T12:00:25+00:00 http://security.googleblog.com/2023/04/securely-hosting-user-data-in-modern.html www.secnews.physaphae.fr/article.php?IdArticle=8328958 False Threat None 2.0000000000000000 GoogleSec - Firm Security Blog open source vulnerabilities have made it clear that securing the supply chains underpinning modern software is an urgent, yet enormous, undertaking. As supply chains get more complicated, enterprise developers need to manage the tidal wave of vulnerabilities that propagate up through dependency trees. Open source maintainers need streamlined ways to vet proposed dependencies and protect their projects. A rise in attacks coupled with increasingly complex supply chains means that supply chain security problems need solutions on the ecosystem level. One way developers can manage this enormous risk is by choosing a more secure language. As part of Google\'s commitment to advancing cybersecurity and securing the software supply chain, Go maintainers are focused this year on hardening supply chain security, streamlining security information to our users, and making it easier than ever to make good security choices in Go. This is the first in a series of blog posts about how developers and enterprises can secure their supply chains with Go. Today\'s post covers how Go helps teams with the tricky problem of managing vulnerabilities in their open source packages. Extensive Package Insights Before adopting a dependency, it\'s important to have high-quality information about the package. Seamless access to comprehensive information can be the difference between an informed choice and a future security incident from a vulnerability in your supply chain. Along with providing package documentation and version history, the Go package discovery site links to Open Source Insights. The Open Source Insights page includes vulnerability information, a dependency tree, and a security score provided by the OpenSSF Scorecard project. Scorecard evaluates projects on more than a dozen security metrics, each backed up with supporting information, and assigns the project an overall score out of ten to help users quickly judge its security stance (example). The Go package discovery site puts all these resources at developers\' fingertips when they need them most-before taking on a potentially risky dependency. Curated Vulnerability Information Large consumers of open source software must manage many packages and a high volume of vulnerabilities. For enterprise teams, filtering out noisy, low quality advisories and false positives from critical vulnerabilities is often the most important task in vulnerability management. If it is difficult to tell which vulnerabilities are important, it is impossible to properly prioritize their remediation. With granular advisory details, the Go vulnerability database removes barriers to vulnerability prioritization and remediation. All vulnerability database entries are reviewed and curated by the Go security team. As a result, entries are accurate and include detailed metadata to improve the quality of vulnerability scans and to make vulnerability information more actionable. This metadata includes information on affected functions, operating systems, and architectures. With this information, vulnerability scanners can reduce the number of false po]]> 2023-04-13T12:04:31+00:00 http://security.googleblog.com/2023/04/supply-chain-security-for-go-part-1.html www.secnews.physaphae.fr/article.php?IdArticle=8327500 False Tool,Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog deps.dev API, which provides free access to the deps.dev dataset of security metadata, including dependencies, licenses, advisories, and other critical health and security signals for more than 50 million open source package versions. Software supply chain attacks are increasingly common and harmful, with high profile incidents such as Log4Shell, Codecov, and the recent 3CX hack. The overwhelming complexity of the software ecosystem causes trouble for even the most diligent and well-resourced developers. We hope the deps.dev API will help the community make sense of complex dependency data that allows them to respond to-or even prevent-these types of attacks. By integrating this data into tools, workflows, and analyses, developers can more easily understand the risks in their software supply chains. The power of dependency data As part of Google\'s ongoing efforts to improve open source security, the Open Source Insights team has built a reliable view of software metadata across 5 packaging ecosystems. The deps.dev data set is continuously updated from a range of sources: package registries, the Open Source Vulnerability database, code hosts such as GitHub and GitLab, and the software artifacts themselves. This includes 5 million packages, more than 50 million versions, from the Go, Maven, PyPI, npm, and Cargo ecosystems-and you\'d better believe we\'re counting them! We collect and aggregate this data and derive transitive dependency graphs, advisory impact reports, OpenSSF Security Scorecard information, and more. Where the deps.dev website allows human exploration and examination, and the BigQuery dataset supports large-scale bulk data analysis, this new API enables programmatic, real-time access to the corpus for integration into tools, workflows, and analyses. The API is used by a number of teams internally at Google to support the security of our own products. One of the first publicly visible uses is the GUAC integration, which uses the deps.dev data to enrich SBOMs. We have more exciting integrations in the works, but we\'re most excited to see what the greater open source community builds! We see the API as being useful for tool builders, researchers, and tinkerers who want to answer questions like: What versions are available for this package? What are the licenses that cover this version of a package-or all the packages in my codebase? How many dependencies does this package have? What are they? Does the latest version of this package include changes to dependencies or licenses? What versions of what packages correspond to this file? Taken together, this information can help answer the most important overarching question: how much risk would this dependency add to my project? The API can help surface critical security information where and when developers can act. This data can be integrated into: IDE Plugins, to make dependency and security information immediately available. CI]]> 2023-04-11T12:11:33+00:00 http://security.googleblog.com/2023/04/announcing-depsdev-api-critical.html www.secnews.physaphae.fr/article.php?IdArticle=8326702 False Tool,Vulnerability None 2.0000000000000000 GoogleSec - Firm Security Blog U.S. Executive Order on Improving the Nation's Cybersecurity requirements for vulnerability disclosure programs and assurances for software used by the US government will go into effect later this year. Finding and fixing security vulnerabilities has never been more important, yet with increasing interest in the area, the vulnerability management space has become fragmented-there are a lot of new tools and competing standards. In 2021, we announced the launch of OSV, a database of open source vulnerabilities built partially from vulnerabilities found through Google's OSS-Fuzz program. OSV has grown since then and now includes a widely adopted OpenSSF schema and a vulnerability scanner. In this blog post, we'll cover how these tools help maintainers track vulnerabilities from discovery to remediation, and how to use OSV together with other SBOM and VEX standards. Vulnerability Databases The lifecycle of a known vulnerability begins when it is discovered. To reach developers, the vulnerability needs to be added to a database. CVEs are the industry standard for describing vulnerabilities across all software, but there was a lack of an open source centric database. As a result, several independent vulnerability databases exist across different ecosystems. To address this, we announced the OSV Schema to unify open source vulnerability databases. The schema is machine readable, and is designed so dependencies can be easily matched to vulnerabilities using automation. The OSV Schema remains the only widely adopted schema that treats open source as a first class citizen. Since becoming a part of OpenSSF, the OSV Schema has seen adoption from services like GitHub, ecosystems such as Rust and Python, and Linux distributions such as Rocky Linux. Thanks to such wide community adoption of the OSV Schema, OSV.dev is able to provide a distributed vulnerability database and service that pulls from language specific authoritative sources. In total, the OSV.dev database now includes 43,302 vulnerabilities from 16 ecosystems as of March 2023. Users can check OSV for a comprehensive view of all known vulnerabilities in open source. Every vulnerability in OSV.dev contains package manager versions and git commit hashes, so open source users can easily determine if their packages are impacted because of the familiar style of versioning. Maintainers are also familiar with OSV's community driven and distributed collaboration on the development of OSV's database, tools, and schema. Matching The next step in managing vulnerabilities is to determine project dependencies and their associated vulnerabilities. Last December we released OSV-Scanner, a free, open source tool which scans software projects' lockfiles, SBOMs, or git repositories to identify vulnerabilities found in the ]]> 2023-03-08T12:04:53+00:00 http://security.googleblog.com/2023/03/osv-and-vulnerability-life-cycle.html www.secnews.physaphae.fr/article.php?IdArticle=8316726 False Tool,Vulnerability None 4.0000000000000000 GoogleSec - Firm Security Blog Google Safe Browsing as well as antivirus software both block file-based UwS more effectively now, which was originally the goal of the Chrome Cleanup Tool. Where file-based UwS migrated over to extensions, our substantial investments in the Chrome Web Store review process have helped catch malicious extensions that violate the Chrome Web Store's policies. Finally, we've observed changing trends in the malware space with techniques such as Cookie Theft on the rise – as such, we've doubled down on defenses against such malware via a variety of improvements including hardened authentication workflows and advanced heuristics for blocking phishing and social engineering emails, malware landing pages, and downloads. What to expect Starting in Chrome 111, users will no longer be able to request a Chrome Cleanup Tool scan through Safety Check or leverage the "Reset settings and cleanup" option offered in chrome://settings on Windows. Chrome will also remove the component that periodically scans Windows machines and prompts users for cleanup should it find anything suspicious. Even without the Chrome Cleanup Tool, users are automatically protected by Safe Browsing in Chrome. Users also have the option to turn on Enhanced protection by navigating to chrome://settings/security – this mode substantially increases protection from dangerous websites and downloads by sharing real-time data with Safe Browsing. While we'll miss the Chrome Cleanup Tool, we wanted to take this opportunity to acknowledge its role in combating UwS for the past 8 years. We'll continue to monitor user feedback and trends in the malware ecosystem, and when adversaries adapt their techniques again – which they will – we'll be at the ready. As always, please feel free to send us feedback or find us on Twitter @googlechrome. ]]> 2023-03-08T11:59:13+00:00 http://security.googleblog.com/2023/03/thank-you-and-goodbye-to-chrome-cleanup.html www.secnews.physaphae.fr/article.php?IdArticle=8316727 False Malware,Tool None 3.0000000000000000 GoogleSec - Firm Security Blog Google Trust Services TLS certificates easier for Google Domains customers. With this integration, all Google Domains customers will be able to acquire public certificates for their websites at no additional cost, whether the site runs on a Google service or uses another provider. Additionally, Google Domains is now making an API available to allow for DNS-01 challenges with Google Domains DNS servers to issue and renew certificates automatically.Like the existing Google Cloud integration, Automatic Certificate Management Environment (ACME) protocol is used to enable seamless automatic lifecycle management of TLS certificates. These certificates are issued by the same Certificate Authority (CA) Google uses for its own sites, so they are widely supported across the entire spectrum of devices used to access your services.How do I use it?Using ACME ensures your certificates are renewed automatically and many hosting services already support ACME. If you're running your own web servers / services, there are ACME clients that integrate easily with common servers. To use this feature, you will need an API key called an External Account Binding key. This enables your certificate requests to be associated with your Google Domains account. You can get an API key by visiting Google Domains and navigating to the Security page for your domain. There you'll see a section for Google Trust Services where you can get your EAB Key.Example of EAB Credentials in Google DomainsAs an example, with the popular Certbot ACME client, the configuration to register an account looks like:certbot register --email --no-eff-email --server "https://dv.acme-v02.api.pki.goog/directory"  --eab-kid "" --eab-hmac-key ""The EAB_KEY_ID and EAB_HMAC_KEY are both provided on your Google Domains security page.After the account is created, you may issue certificates by running:certbot certonly -d --server "https://dv.acme-v02.api.pki.goog/directory" --standaloneThen fo]]> 2023-03-02T12:42:15+00:00 http://security.googleblog.com/2023/03/google-trust-services-now-offers-tls.html www.secnews.physaphae.fr/article.php?IdArticle=8315041 False None None 2.0000000000000000 GoogleSec - Firm Security Blog Chrome Browser Cloud Management is a single destination for applying Chrome Browser policies and security controls across Windows, Mac, Linux, iOS and Android. You also get deep visibility into your browser fleet including which browsers are out of date, which extensions your users are using and bringing insight to potential security blindspots in your enterprise. Managing Chrome from the cloud allows Google Workspace admins to enforce enterprise protections and policies to the whole browser on fully managed devices, which no longer requires a user to sign into Chrome to have policies enforced. You can also enforce policies that apply when your managed users sign in to Chrome browser on any Windows, Mac, or Linux computer (via Chrome Browser user-level management) --not just on corporate managed devices. This enables you to keep your corporate data and users safe, whether they are accessing work resources from fully managed, personal, or unmanaged devices used by your vendors. Getting started is easy. If your organization hasn't already, check out this guide for steps on how to enroll your devices. 2. Enforce built-in protections against Phishing, Ransomware & Malware Chrome uses Google's Safe Browsing technology to help protect billions of devices every day by showing warnings to users when they attempt to navigate to dangerous sites or download dangerous files. Safe Browsing is enabled by default for all users when they download Chrome. As an administrator, you can prevent your users from disabling Safe Browsing by enforcing the SafeBrowsingProtectionLevel policy. Over the past few years, we've seen threats on the web becoming increasingly sophisticated. Turning on Enhanced Safe Browsing will substantially increase protection ]]> 2023-03-01T11:59:44+00:00 http://security.googleblog.com/2023/03/8-ways-to-secure-chrome-browser-for.html www.secnews.physaphae.fr/article.php?IdArticle=8314677 False Ransomware,Malware,Tool,Threat,Guideline,Cloud None 3.0000000000000000 GoogleSec - Firm Security Blog CTV/OTT Device & App Identification Guidelines and IFA Guidelines. These guidelines, both of which were developed by the IAB Tech Lab, foster greater transparency, which in turn reduces the risk of invalid traffic on CTV. More information and details about using these resources can be found in the following guide: Protecting your ad-supported CTV experiences.Collaborating on standards and solutionsNo single company or industry group can solve this challenge on their own, we need to work collaboratively to solve the problem. Fortunately, we're already seeing constructive efforts in this direction with industry-wide standards.For example, the broad implementation of the IAB Tech Lab's app-ads.txt and its web counterpart, ads.txt, have brought greater transparency to the digital advertising supply chain and have helped combat ad fraud by allowing advertisers to verify the sellers from whom they buy inventory. In 2021, the IAB Tech Lab extended the app-ads.txt standard to CTV in order to better protect and support CTV advertisers. This update is the first of several industry-wide steps that have been taken to further protect CTV advertising. In early 2022, the IAB Tech Lab released the ads.cert 2.0 “protocol suite,” along with a proposal to utilize this new standard to secure server-side connections (including for server-side ad insertion). Ads.cert 2.0 will also power future industry standards focused on securing the supply chain and preventing misrepresentation.In addition to these efforts, the Media Rating Council (MRC) also engaged with stakeholders to develop its ]]> 2023-02-28T09:00:14+00:00 http://security.googleblog.com/2023/02/our-commitment-to-fighting-invalid.html www.secnews.physaphae.fr/article.php?IdArticle=8314163 False Guideline None 3.0000000000000000 GoogleSec - Firm Security Blog announced GSMA working party, which will develop a first-of-its-kind smartphone security certification program. The program will leverage the Consumer Mobile Device Protection Profile (CMD PP) specification released by ETSI, a European Standards Development Organization (SDO), and will provide a consistent way to evaluate smartphones for critical capabilities like encryption, security updates, biometrics, networking, trusted hardware, and more. This initiative should help address a significant gap in the market for consumers and policy makers, who will greatly benefit from a new, central security resource. Most importantly, these certification programs will evaluate connected devices across industry-accepted criteria. Widely-used devices, including smartphones and tablets, which currently do not have a familiar security benchmark or system in place, will be listed with key information on device protection capabilities to bring more transparency to users. We hope this industry-run certification program can also benefit users and support policy makers in their work as they address baseline requirements and harmonization of standards.As policy makers consider changes through regulation and legislation, such as the UK's Product Security and Telecommunications Infrastructure Act (PSTI), and emerging regulation like the EU Cyber Security and Cyber Resilience Acts, we share the concerns that today we are not equipped with globally recognized standards that are critical to increased security across the ecosystem. We join governments in the call to come together to ensure that we can build workable, harmonized standards to protect the security of users and mobile infrastructure today and build the resilience needed to protect our future. The Importance of Harmonized Standards for Connected DevicesConnected devices, not just smartphones, are increasingly becoming the primary touchpoint for the most important aspects of our personal lives. From controlling the temperature of your home, to tracking your latest workout – connected devices have become embedded in our day-to-day tasks and activities. As consumers increasingly entrust more of their lives to their connected devices, they're right to question the security protections provided and demand more transparency from manufacturers. After we participated in a recent White House Workshop on IoT security labeling, we shared more about our commitment to security and transparency by announcing the extension of device security assessments – which started with Pixel 3 and now includes Nest, and Fitbit hardware. We have and always will strive to ensure our newly released products comply with the most prevalent security baselines that are defined by industry-recognized standards organizations. We will also]]> 2023-02-23T11:59:32+00:00 http://security.googleblog.com/2023/02/moving-connected-device-security.html www.secnews.physaphae.fr/article.php?IdArticle=8312905 False None None 4.0000000000000000 GoogleSec - Firm Security Blog past years, we are sharing our 2022 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! AndroidThe Android VRP had an incredible record breaking year in 2022 with $4.8 million in rewards and the highest paid report in Google VRP history of $605,000! In our continued effort to ensure the security of Google device users, we have expanded the scope of Android and Google Devices in our program and are now incentivizing vulnerability research in the latest versions of Google Nest and Fitbit! For more information on the latest program version and qualifying vulnerability reports, please visit our public rules page. We are also excited to share that the invite-only Android Chipset Security Reward Program (ACSRP) - a private vulnerability reward program offered by Google in collaboration with manufacturers of Android chipsets - rewarded $486,000 in 2022 and received over 700 valid security reports. We would like to give a special shoutout to some of our top researchers, whose continued hard work helps to keep Android safe and secure: Submitting an impressive 200+ vulnerabilities to the Android VRP this year, Aman Pandey of Bugsmirror remains one of our program's top researchers. Since submitting their first report in 2019, Aman has reported more than 500 vulnerabilities to the program. Their hard work helps ensure the safety of our users; a huge thank you for all of their hard work! Zinuo Han of OPPO Amber Security Lab ]]> 2023-02-22T12:01:42+00:00 http://security.googleblog.com/2023/02/vulnerability-reward-program-2022-year.html www.secnews.physaphae.fr/article.php?IdArticle=8312532 False Vulnerability,Guideline None 2.0000000000000000 GoogleSec - Firm Security Blog publications, talks, Pwn2Own contest winners, and CVEs targeting exploitation of vulnerabilities in firmware running in these secondary processors. Bugs remotely exploitable over the air (eg. WiFi and cellular baseband bugs) are of particular concern and, therefore, are popular within the security research community. These types of bugs even have their own categorization in well known 3rd party exploit marketplaces. Regardless of whether it is remote code execution within the WiFi SoC or within the cellular baseband, a common and resonating theme has been the consistent lack of exploit mitigations in firmware. Conveniently, Android has significant experience in enabling exploit mitigations across critical attack surfaces. Applying years worth of lessons learned in systems hardening Over the last few years, we have successfully enabled compiler-based mitigations in Android - on the AP - which add additional layers of defense across the platform, making it harder to build reproducible exploits and to prevent certain types of bugs from becoming vulnerabilities. Building on top of these successes and lessons learned, we're applying the same principles to hardening the security of firmware that runs outside of Android per se, directly on the bare-metal hardware. In particular, we are working with our ecosystem partners in several areas aimed at hardening the security of firmware that interacts with Android: Exploring and enabling compiler-based sanitizers (Bound]]> 2023-02-21T12:29:09+00:00 http://security.googleblog.com/2023/02/hardening-firmware-across-android.html www.secnews.physaphae.fr/article.php?IdArticle=8312262 False Vulnerability None 4.0000000000000000 GoogleSec - Firm Security Blog planted a flag in the sand: “The incentives for developing and selling technology have eclipsed customer safety in importance. […] Americans…have unwittingly come to accept that it is normal for new software and devices to be indefensible by design. They accept products that are released to market with dozens, hundreds, or even thousands of defects. They accept that the cybersecurity burden falls disproportionately on consumers and small organizations, which are often least aware of the threat and least capable of protecting themselves.”We think they're right. It's time for companies to step up on their own and work with governments to help fix a flawed ecosystem. Just look at the growing threat of ransomware, where bad actors lock up organizations' systems and demand payment or ransom to restore access. Ransomware affects every industry, in every corner of the globe – and it thrives on pre-existing vulnerabilities: insecure software, indefensible architectures, and inadequate security investment. Remember that sophisticated ransomware operators have bosses and budgets too. They increase their return on investment by exploiting outdated and insecure technology systems that are too hard to defend. Alarmingly, the most significant source of compromise is through exploitation of known vulnerabilities, holes sometimes left unpatched for years. While law enforcement works to bring ransomware operators to justice, this merely treats the symptoms of the problem. Treating the root causes will require addressing the underlying sources of digital vulnerabilities. As Easterly and Goldstein rightly point out, “secure by default” and “secure by design” should be table stakes. The bottom line: People deserve products that are secure by default and systems that are built to withstand the growing onslaught from attackers. Safety should be fundamental: built-in, enabled out of the box, and not added on as an afterthought. In other words, we need secure products, not security products. That's why Google has worked to build security in – often making it invisible – to our users. Many of our most significant security features, including innovations like SafeBrowsing, do their best work behind the scenes for our core consumer products. There's come to be an unfortunate belief that security features are cumbersome and hurt user experience. That can be true – but it doesn't need to be. We can make the safe path the easiest, most helpful path for people using our products. Our approach to multi-factor authentication – one of the most important controls to defend against phishing attacks – provides a great example. Since 2021, we've turned on 2-Step Verification (2SV) by default for hundreds of millions of people to add an additional layer of security across their online accounts. If we had simply announced 2SV as an available option for people to enroll in, it would have failed like so many other security add-ons. Instead, we pioneered an approach using in-app notifications that was so seamless and integrated, many of the millions of people we auto-enrolled never noticed they adopted 2SV. We've taken this approach even further by build]]> 2023-02-13T12:01:11+00:00 http://security.googleblog.com/2023/02/the-us-government-says-companies-should.html www.secnews.physaphae.fr/article.php?IdArticle=8309678 False Ransomware,Threat None 3.0000000000000000 GoogleSec - Firm Security Blog launching in 2016, Google's free OSS-Fuzz code testing service has helped get over 8800 vulnerabilities and 28,000 bugs fixed across 850 projects. Today, we're happy to announce an expansion of our OSS-Fuzz Rewards Program, plus new features in OSS-Fuzz and our involvement in supporting academic fuzzing research. Refreshed OSS-Fuzz rewards The OSS-Fuzz project's purpose is to support the open source community in adopting fuzz testing, or fuzzing - an automated code testing technique for uncovering bugs in software. In addition to the OSS-Fuzz service, which provides a free platform for continuous fuzzing to critical open source projects, we established an OSS-Fuzz Reward Program in 2017 as part of our wider Patch Rewards Program. We've operated this successfully for the past 5 years, and to date, the OSS-Fuzz Reward Program has awarded over $600,000 to over 65 different contributors for their help integrating new projects into OSS-Fuzz. Today, we're excited to announce that we've expanded the scope of the OSS-Fuzz Reward Program considerably, introducing many new types of rewards! These new reward types cover contributions such as: Project fuzzing coverage increases Notable FuzzBench fuzzer integrations Integrating a new sanitizer (example) that finds two new vulnerabilities These changes boost the total rewards possible per project integration from a maximum of $20,000 to $30,000 (depending on the criticality of the project). In addition, we've also established two new reward categories that reward wider improvements across all OSS-Fuzz projects, with up to $11,337 available per category. For more details, see the fully updated rules for our dedicated OSS-Fuzz Reward Program. OSS-Fuzz improvements We've continuously made improvements to OSS-Fuzz's infrastructure over the years and expanded our language offerings to cover C/C++, Go, Rust, Java, Python, and Swift, and have introduced support for new frameworks such as FuzzTest. Additionally, as part of an ongoing collaboration with Code Intelligence, we'll soon have support for JavaScript fuzzing through Jazzer.js. FuzzIntrospector support Last year, we launched the OpenSSF FuzzIntrospector tool and integrated it into OSS-Fuzz. We've continued to build on this by adding new language support and better analysis, and now C/C++, Python, and Java projects integrated into OSS-Fuzz have detailed insights on how the coverage and fuzzing effectiveness for a project can be improved. The ]]> 2023-02-01T13:00:49+00:00 http://security.googleblog.com/2023/02/taking-next-step-oss-fuzz-in-2023.html www.secnews.physaphae.fr/article.php?IdArticle=8306318 False Tool None 5.0000000000000000 GoogleSec - Firm Security Blog Dev Security Policy” Web PKI public discussion forum Google Group in December 2022. Google Chrome communicated its distrust of TrustCor in the public forum on December 15, 2022.The Chrome Security Team prioritizes the security and privacy of Chrome's users, and we are unwilling to compromise on these values. Google includes or removes CA certificates within the Chrome Root Store as it deems appropriate for user safety in accordance with our policies. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability. Behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations whose CA certificates are included in the Chrome Root Store. Due to a loss of confidence in its ability to uphold these fundamental principles and to protect and safeguard Chrome's users, certificates issued by TrustCor Systems will no longer be recognized as trusted by: Chrome versions 111 (landing in Beta approximately February 9, 2023 and Stable approximately March 7, 2023) and greater; and Older versions of Chrome capable of receiving Component Updates after Chrome 111's Stable release date. This change was first communicated in the Mozilla “Dev Security Policy” Web PKI public discussion forum Google Group on December 15, 2022. This change will be implemented via our existing mechanisms to respond to CA incidents via: An integrated certificate blocklist, and Removal of certificates included in the Chrome Root Store. Beginning approximately March 7, 2023, navigations to websites that use a certificate that chains to one of the roots detailed below will be considered insecure and result in a full page certificate error interstitial. Affected Certificates (SHA-256 fingerprint): d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c 0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965 5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c This change will be integrated into the Chromium open-source project as part of a default build. Questions about the expected behavior in specific Chromium-based browsers should be directed to their maintainers. This change will be incorporated as part of the regular Chrome release process to ensure sufficient time for testing and replacing affected certificates by website operators. Information about release timetables and milestones is available at https://chromiumdash.appspot.com/schedule. Beginning approximately February 9, 2023, website operators can preview these changes in Chrome 111 Beta. Website operators will also be able to preview the change sooner, using our Dev and Canary channels. The majority of users will not encounter behavior changes until the release of Chrome 111 to the Stable channel, approximately March 7, 2023. Summarizing security response of other Google products: Android has removed TrustCor's root CA certificates from th]]> 2023-01-13T12:29:06+00:00 http://security.googleblog.com/2023/01/sustaining-digital-certificate-security_13.html www.secnews.physaphae.fr/article.php?IdArticle=8300952 False None None 3.0000000000000000 GoogleSec - Firm Security Blog production Rust toolchain to our build system. This will enable us to include Rust code in the Chrome binary within the next year. We're starting slow and setting clear expectations on what libraries we will consider once we're ready. In this blog post, we will discuss how we arrived at the decision to support third-party Rust libraries at this time, and not broader usage of Rust in Chromium. Why We Chose to Bring Rust into ChromiumOur goal in bringing Rust into Chromium is to provide a simpler (no IPC) and safer (less complex C++ overall, no memory safety bugs in a sandbox either) way to satisfy the rule of two, in order to speed up development (less code to write, less design docs, less security review) and improve the security (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code) of Chrome. And we believe that we can use third-party Rust libraries to work toward this goal. Rust was developed by Mozilla specifically for use in writing a browser, so it's very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant. We know that C++ and Rust can play together nicely, through tools like cxx, autocxx bindgen, cbindgen, diplomat, and (experimental) crubit. However there are also limitations. We can expect that the shape of these limitations will change in time through new or improved tools, but the decisions and descriptions here are based on the current state of technology. How Chromium Will Support the Use of RustThe Chrome Security team has been investing time into researching how we should approach using Rust alongside our C++ code. Understanding the implications of incrementally moving to writing Rust instead of C++, even in the middle of our software stack. What the limits of safe, simple, and reliable interop might be. Based on our research, we landed on two outcomes for Chromium. We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++. We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don't hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without ]]> 2023-01-12T12:26:06+00:00 http://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html www.secnews.physaphae.fr/article.php?IdArticle=8300636 False None None 3.0000000000000000 GoogleSec - Firm Security Blog launched in 2019 with a mission to protect Android users from bad apps through shared intelligence and coordinated detection between alliance partners. Earlier this year, the App Defense Alliance expanded to include new initiatives outside of malware detection and is now the home for several industry-led collaborations including Malware Mitigation, MASA (Mobile App Security Assessment) & CASA (Cloud App Security Assessment). With a new dedicated landing page at appdefensealliance.dev, the ADA has an expanded mission to protect Android users by removing threats while improving app quality across the ecosystem. Let's walk through some of the latest program updates from the past year, including the addition of new ADA members. Malware MitigationTogether, with the founding ADA members - Google, ESET, Lookout, and Zimperium, the alliance has been able to reduce the risk of app-based malware and better protect Android users. These partners have access to mobile apps as they are being submitted to the Google Play Store and scan thousands of apps daily, acting as another, vital set of eyes prior to an app going live on Play. Knowledge sharing and industry collaboration are important aspects in securing the world from attacks and that's why we're continuing to invest in the program. New ADA MembersWe're excited to see the ADA expand with the additions of McAfee and Trend Micro. Both McAfee and Trend Micro are leaders in the antivirus space and we look forward to their contributions to the program. Mobile App Security Assessment (MASA)With consumers spending four to five hours per day in mobile apps, ensuring the safety of these services is more important than ever. According to Data.ai, the pandemic accelerated existing mobile habits - with app categories like finance growing 25% YoY and users spending over 100 billion hours in shopping apps. That's why the ADA introduced MASA (Mobile App Security Assessment), which allows developers to have their apps independently validated against the Mobile Application Security Verification Standard (MASVS standard) under the OWASP Mobile Application Security project. The project's mission is to “Define the industry standard for mobile application security,” and has been used by both public and private sector organizations as a form of industry best practices when it comes to mobile application security. Developers can work directly with an ADA Authorized Lab to have their apps evaluated against a set of MASVS L1 requirements. Once successful, the app's validation is listed in the recently launched App Validation Directory, which provides users a single place to view all app validations. The Directory also allows users to access more assessment details including validation date, test lab, and a report showing all test steps and requirements. The Directory will be updated over time with new features and search functionality to make it more user friendly. The Google Play Store is the first commercial app store to recognize and display a badge for any app that has completed an independent security review through ADA MASA. The badge is displayed within an app's respective ]]> 2022-12-15T20:51:24+00:00 http://security.googleblog.com/2022/12/app-defense-alliance-expansion.html www.secnews.physaphae.fr/article.php?IdArticle=8294655 False Malware,Guideline,Prediction Uber 2.0000000000000000 GoogleSec - Firm Security Blog OSV-Scanner, a free tool that gives open source developers easy access to vulnerability information relevant to their project. Last year, we undertook an effort to improve vulnerability triage for developers and consumers of open source software. This involved publishing the Open Source Vulnerability (OSV) schema and launching the OSV.dev service, the first distributed open source vulnerability database. OSV allows all the different open source ecosystems and vulnerability databases to publish and consume information in one simple, precise, and machine readable format. The OSV-Scanner is the next step in this effort, providing an officially supported frontend to the OSV database that connects a project's list of dependencies with the vulnerabilities that affect them. OSV-Scanner Software projects are commonly built on top of a mountain of dependencies-external software libraries you incorporate into a project to add functionalities without developing them from scratch. Each dependency potentially contains existing known vulnerabilities or new vulnerabilities that could be discovered at any time. There are simply too many dependencies and versions to keep track of manually, so automation is required. Scanners provide this automated capability by matching your code and dependencies against lists of known vulnerabilities and notifying you if patches or updates are needed. Scanners bring incredible benefits to project security, which is why the 2021 U.S. Executive Order for Cybersecurity included this type of automation as a requirement for national standards on secure software development.The OSV-Scanner generates reliable, high-quality vulnerability information that closes the gap between a developer's list of packages and the information in vulnerability databases. Since the OSV.dev database is open source and distributed, it has several benefits in comparison with closed source advisory databases and scanners: Each advisory comes from an open and authoritative source (e.g. the RustSec Advisory Database) Anyone can suggest improvements to advisories, resulting in a very high quality database The OSV format unambiguously stores information about affected versions in a machine-readable format that precisely maps onto a developer's list of packages The above all results in fewer, more actionable vulnerability notifications, which reduces the time needed to resolve them Running OSV-Scanner on your project will first find all the transitive dependencies that are being used by analyzing manifests, SBOMs, and commit hashes. The scanner then connects this information with the OSV database and displays the vulnerabilities relevant to your project. ]]> 2022-12-13T13:00:47+00:00 http://security.googleblog.com/2022/12/announcing-osv-scanner-vulnerability.html www.secnews.physaphae.fr/article.php?IdArticle=8294656 False Tool,Vulnerability None 3.0000000000000000 GoogleSec - Firm Security Blog Live Translate without sharing continuous sensing data with service providers, including Google. PCC is part of Protected Computing, a toolkit of technologies that transform how, when, and where data is processed to technically ensure its privacy and safety. For example, by employing cloud enclaves, edge processing, or end-to-end encryption we ensure sensitive data remains in exclusive control of the user. How Private Compute Core works PCC is designed to enable innovative features while keeping the data needed for them confidential from other subsystems. We do this by using techniques such as limiting Interprocess Communications (IPC) binds and using isolated processes. These are included as part of the Android Open Source Project and controlled by publicly available surfaces, such as Android framework APIs. For features that run inside PCC, continuous sensing data is processed safely and seamlessly while keeping it confidential. To stay useful, any machine learning feature has to get better over time. To keep the models that power PCC features up to date, while still keeping the data private, we leverage federated learning and analytics. Network calls to improve the performance of these models can be monitored using Private Compute Services. Let us show you our work The publicly-verifiable architectures in PCC demonstrate how we strive to deliver confidentiality and control, and do it in a way that is verifiable and visible to users. In addition to this blog, we provide this transparency through public documentation and open-source code - we hope you'll have a look below. To explain in even more detail, we've published a technical whitepaper for researchers and interested members of the community. In it, we describe data protections in-depth, the processes and mechanisms we've built, and includ]]> 2022-12-08T11:59:15+00:00 http://security.googleblog.com/2022/12/trust-in-transparency-private-compute.html www.secnews.physaphae.fr/article.php?IdArticle=8289196 False None None 3.0000000000000000 GoogleSec - Firm Security Blog How Hash-Based Safe Browsing Works in Google Chrome, we wanted to provide more details about Safe Browsing's Enhanced Protection mode in Chrome. Specifically, how it came about, the protections that are offered and what it means for your data. Security and privacy have always been top of mind for Chrome. Our goal is to make security effortless for you while browsing the web, so that you can go about your day without having to worry about the links that you click on or the files that you download. This is why Safe Browsing's phishing and malware protections have been a core part of Chrome since 2007. You may have seen these in action if you have ever come across one of our red warning pages. We show these warnings whenever we believe a site that you are trying to visit or file that you are trying to download might put you at risk for an attack. To give you a better understanding of how the Enhanced Protection mode in Safe Browsing provides the strongest level of defense it's useful to know what is offered in Standard Protection. Standard Protection Enabled by default in Chrome, Standard Protection was designed to be privacy preserving at its core by using hash-based checks. This has been effective at protecting users by warning millions of users about dangerous websites. However, hash-based checks are inherently limited as they rely on lookups to a list of known bad sites. We see malicious actors moving fast and constantly evolving their tactics to avoid detection using sophisticated techniques. To counter this, we created a stronger and more customized level of protection that we could offer to users. To this end, we launched Enhanced Protection in 2020, which builds upon the Standard Protection mode in Safe Browsing to keep you safer. Enhanced Protection This is the fastest and strongest level of protection against dangerous sites and downloads that Safe Browsing offers in Chrome. It enables more advanced detection techniques that adapt quickly as malicious activity evolves. As a result, Enhanced Protection users are phished 20-35% less than users on Standard Protection. A few of these features include: Real time URL checks: By checking with Google Safe Browsing's servers in real time before navigating to an uncommon site you're visiting, Chrome provides the best protection against dangerous sites and uses advanced machine learning models to continuously stay up to date. File checks before downloading: In addition to Chrome's standard checks of downloaded files, Enhanced Protection users can choose to upload suspicious files to be scanned by Google Safe Browsing's full suite of malware detection technology before opening the file. This helps catch brand new malware that Safe Browsing has not scanned bef]]> 2022-12-05T13:03:18+00:00 http://security.googleblog.com/2022/12/enhanced-protection-strongest-level-of.html www.secnews.physaphae.fr/article.php?IdArticle=8287915 False Malware None 3.0000000000000000 GoogleSec - Firm Security Blog across products, and across the industry. On Android, we're now seeing something different - a significant drop in memory safety vulnerabilities and an associated drop in the severity of our vulnerabilities. Looking at vulnerabilities reported in the Android security bulletin, which includes critical/high severity vulnerabilities reported through our vulnerability rewards program (VRP) and vulnerabilities reported internally, we see that the number of memory safety vulnerabilities have dropped considerably over the past few years/releases. From 2019 to 2022 the annual number of memory safety vulnerabilities dropped from 223 down to 85. This drop coincides with a shift in programming language usage away from memory unsafe languages. Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language. As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android's total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android's vulnerabilities. ]]> 2022-12-01T11:58:33+00:00 http://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html www.secnews.physaphae.fr/article.php?IdArticle=8286362 False Vulnerability None 4.0000000000000000 GoogleSec - Firm Security Blog 2022-11-02T14:12:24+00:00 http://security.googleblog.com/2022/11/our-principles-for-iot-security-labeling.html www.secnews.physaphae.fr/article.php?IdArticle=7981120 False Vulnerability,Threat,Guideline None None GoogleSec - Firm Security Blog rise in software supply chain attacks, a Log4j vulnerability of catastrophic severity and breadth, and even an Executive Order on Cybersecurity. It is against this background that Google is seeking contributors to a new open source project called GUAC (pronounced like the dip). GUAC, or Graph for Understanding Artifact Composition, is in the early stages yet is poised to change how the industry understands software supply chains. GUAC addresses a need created by the burgeoning efforts across the ecosystem to generate software build, security, and dependency metadata. True to Google's mission to organize and make the world's information universally accessible and useful, GUAC is meant to democratize the availability of this security information by making it freely accessible and useful for every organization, not just those with enterprise-scale security and IT funding. Thanks to community collaboration in groups such as OpenSSF, SLSA, SPDX, CycloneDX, and others, organizations increasingly have ready access to: Software Bills of Materials (SBOMs) (with SPDX-SBOM-Generator, Syft, kubernetes bom tool) signed attestations about how software was built (e.g. SLSA with SLSA3 Github Actions Builder, Google Cloud Build) vulnerability databases that aggregate information across ecosystems and make vulnerabilities more discoverable and actionable (e.g. OSV.dev, Global Security Database (GSD)). These data are useful on their own, but it's difficult to combine and synthesize the information for a more comprehensive view. The documents are scattered across different databases and producers, are attached to different ecosystem entities, and cannot be easily aggregated to answer higher-level questions about an organization's software assets. To help address this issue we've teamed up with Kusari, Purdue University, and Citi to create GUAC, a free tool to bring together many different sources of software security metadata. We're excited to share the project's proof of concept, which lets you query a small dataset of software metadata including SLSA provenance, SBOMs, and OpenSSF Scorecards. What is GUAC Graph for Understanding Artifact Composition (GUAC) aggregates software security metadata into a high fidelity graph database-normalizing entity identities and mapping standard relationships between them. Querying this graph can drive higher-level organizational outcomes such as audit, policy, risk management, and even developer assistance. Conceptually, GUAC occupies the “aggregation and synthesis” layer of the software supply chain transparency logical model: ]]> 2022-10-20T13:01:02+00:00 http://security.googleblog.com/2022/10/announcing-guac-great-pairing-with-slsa.html www.secnews.physaphae.fr/article.php?IdArticle=7739960 False Tool,Vulnerability Uber None GoogleSec - Firm Security Blog Google Password Manager are kept secure. See our post on the Android Developers Blog for a more general overview.Passkeys are a safer and more secure alternative to passwords. They also replace the need for traditional 2nd factor authentication methods such as text message, app based one-time codes or push-based approvals. Passkeys use public-key cryptography so that data breaches of service providers don't result in a compromise of passkey-protected accounts, and are based on industry standard APIs and protocols to ensure they are not subject to phishing attacks.Passkeys are the result of an industry-wide effort. They combine secure authentication standards created within the FIDO Alliance and the W3C Web Authentication working group with a common terminology and user experience across different platforms, recoverability against device loss, and a common integration path for developers. Passkeys are supported in Android and other leading industry client OS platforms.A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security.The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones. When a passkey is created, only its corresponding public key is stored by the online service. During login, the service uses the public key to verify a signature from the private key. This can only come from one of the user's devices. Additionally, the user is also required to unlock their device or credential store for this to happen, preventing sign-ins from e.g. a stolen phone. To address the common case of device loss or upgrade, a key feature enabled by passkeys is that the same private key can exist on multiple devices. This happens through platform-provided synchronization and backup.]]> 2022-10-12T08:00:03+00:00 http://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html www.secnews.physaphae.fr/article.php?IdArticle=7482583 False Guideline None None GoogleSec - Firm Security Blog 1 Pixel phones also get better every few months with Feature Drops that provide the latest product updates, tips and tricks from Google. And Pixel 7 and Pixel 7 Pro users will receive at least five years of security updates2, so your Pixel gets even more secure over time. Your protection, built into PixelYour digital life and most sensitive information lives on your phone: financial information, passwords, personal data, photos – you name it. With Google Tensor G2 and our custom Titan M2 security chip, Pixel 7 and Pixel 7 Pro have multiple layers of hardware security to help keep you and your personal information safe. We take a comprehensive, end-to-end approach to security with verifiable protections at each layer - the network, application, operating system and multiple layers on the silicon itself. If you use Pixel for your business, this approach helps protect your company data, too. Google Tensor G2 is Pixel's newest powerful processor custom built with Google AI, and makes Pixel 7 faster, more efficient and secure3. Every aspect of Tensor G2 was designed to improve Pixel's performance and efficiency for great battery life, amazing photos and videos. Tensor's built-in security core works with our Titan M2 security chip to keep your personal information, PINs and passwords safe. Titan family chips are also used to protect Google Cloud data centers and Chromebooks, so the same hardware that protects Google servers also secures your sensitive information stored on Pixel. And, in a first for Google, Titan M2 hardware has now been certified under Common Criteria PP0084: the international gold standard for hardware security components also used for identity, SIM cards, and bankcard security chips.]]> 2022-10-11T19:22:42+00:00 http://security.googleblog.com/2022/10/google-pixel-7-and-pixel-7-pro-next.html www.secnews.physaphae.fr/article.php?IdArticle=7482584 False Spam,Malware,Vulnerability,Guideline,Industrial APT 40 None GoogleSec - Firm Security Blog investigate many solutions – both in C++ and in new programming languages. The most common type of memory safety bug is the “use-after-free”. We recently posted about an exciting series of technologies designed to prevent these. Those technologies (collectively, *Scan, pronounced “star scan”) are very powerful but likely require hardware support for sufficient performance. Today we're going to talk about a different approach to solving the same type of bugs. It's hard, if not impossible, to avoid use-after-frees in a non-trivial codebase. It's rarely a mistake by a single programmer. Instead, one programmer makes reasonable assumptions about how a bit of code will work, then a later change invalidates those assumptions. Suddenly, the data isn't valid as long as the original programmer expected, and an exploitable bug results. These bugs have real consequences. For example, according to Google Threat Analysis Group, a use-after-free in the ChromeHTML engine was exploited this year by North Korea. Half of the known exploitable bugs in Chrome are use-after-frees: Diving Deeper: Not All Use-After-Free Bugs Are Equal Chrome has a multi-process architecture, partly to ensure that web content is isolated into a sandboxed “renderer” process where little harm can occur. An attacker therefore usually needs to find and exploit two vulnerabilities - one to achieve code execution in the renderer process, and another bug to break out of the sandbox. The first stage is often the easier one. The attacker has lots of influence in the renderer process. It's easy to arrange memory in a specific way, and the renderer process acts upon many different kinds of web content, giving a large “attack surface” that could potentially be exploited. The second stage, escaping the renderer sandbox, is trickier. Attackers have two options how to do this: They can exploit a bug in the underlying operating system (OS) through the limited interfaces available inside Chrome's sandbox. Or, they can exploit a bug in a more powerful, privileged part of Chrome - like the “browser” process. This process coordinates all the other bits of Chrome, so fundamentally has to be all-powerful. We imagine the attackers squeezing through the narrow part of a funnel: ]]> 2022-09-13T12:59:14+00:00 http://security.googleblog.com/2022/09/use-after-freedom-miracleptr.html www.secnews.physaphae.fr/article.php?IdArticle=6873356 False Vulnerability,Threat,Guideline None None GoogleSec - Firm Security Blog OSS-Fuzz-our community fuzzing service that regularly checks 700 critical open source projects for bugs-detected a serious vulnerability (CVE-2022-3008): a bug in the TinyGLTF project that could have allowed attackers to execute malicious code in projects using TinyGLTF as a dependency. The bug was soon patched, but the wider significance remains: OSS-Fuzz caught a trivially exploitable command injection vulnerability. This discovery shows that fuzzing, a type of testing once primarily known for detecting memory corruption vulnerabilities in C/C++ code, has considerable untapped potential to find broader classes of vulnerabilities. Though the TinyGLTF library is written in C++, this vulnerability is easily applicable to all programming languages and confirms that fuzzing is a beneficial and necessary testing method for all software projects. Fuzzing as a public service OSS-Fuzz was launched in 2016 in response to the Heartbleed vulnerability, discovered in one of the most popular open source projects for encrypting web traffic. The vulnerability had the potential to affect almost every internet user, yet was caused by a relatively simple memory buffer overflow bug that could have been detected by fuzzing-that is, by running the code on randomized inputs to intentionally cause unexpected behaviors or crashes that signal bugs. At the time, though, fuzzing was not widely used and was cumbersome for developers, requiring extensive manual effort. Google created OSS-Fuzz to fill this gap: it's a free service that runs fuzzers for open source projects and privately alerts developers to the bugs detected. Since its launch, OSS-Fuzz has become a critical service for the open source community, helping get more than 8,000 security vulnerabilities and more than 26,000 other bugs in open source projects fixed. With time, OSS-Fuzz has grown beyond C/C++ to detect problems in memory-safe languages such as Go, Rust, and Python. Google Cloud's Assured Open Source Software Service, which provides organizations a secure and curated set of open source dependencies, relies on OSS-Fuzz as a foundational layer of security scanning. OSS-Fuzz is also the basis for free fuzzing tools for the community, such as ClusterFuzzLite, which gives developers a streamlined way to fuzz both open source and proprietary code before committing changes to their projects. All of these efforts are part of Google's $10B commitment to improving cybersecurity and continued work to make open source software more secure for everyone. New classes of vulnerabilities Last December, OSS-Fuzz ]]> 2022-09-08T12:00:15+00:00 http://security.googleblog.com/2022/09/fuzzing-beyond-memory-corruption.html www.secnews.physaphae.fr/article.php?IdArticle=6786657 False Vulnerability None None