Preventing Privilege Escalation

Total Page:16

File Type:pdf, Size:1020Kb

Preventing Privilege Escalation Preventing Privilege Escalation Niels Provos Markus Friedl Peter Honeyman CITI, University of Michigan GeNUA CITI, University of Michigan Abstract gain extra privilege after successful authentication lim- its the degree of escalation because the user is already Many operating system services require special priv- authorized to hold some privilege. On the other hand, ilege to execute their tasks. A programming error in a a remote adversary gaining superuser privilege with no privileged service opens the door to system compromise authentication presents a greater degree of escalation. in the form of unauthorized acquisition of privileges. In For services that are part of the critical Internet the worst case, a remote attacker may obtain superuser infrastructure is it particularly important to protect privileges. In this paper, we discuss the methodology against programming errors. Sometimes these services and design of privilege separation, a generic approach need to retain special privilege throughout their life- that lets parts of an application run with different levels time. For example, in SSH, the SSH daemon needs to of privilege. Programming errors occurring in the un- know the private host key during re-keying to authenti- privileged parts can no longer be abused to gain unau- cate the key exchange. The daemon also needs to open thorized privileges. Privilege separation is orthogonal new pseudo-terminals when the SSH client so requests. to capability systems or application confinement and These operations require durable special privilege as enhances the security of such systems even further. they can be requested at any time during the lifetime Privilege separation is especially useful for system of a SSH connection. In current SSH implementations, services that authenticate users. These services exe- therefore, an exploitable programming error allows an cute privileged operations depending on internal state adversary to obtain superuser privilege. not known to an application confinement mechanism. Several approaches to help prevent security prob- As a concrete example, the concept of privilege sep- lems related to programming errors have been pro- aration has been implemented in OpenSSH. However, posed. Among them are type-safe languages [30] and privilege separation is equally useful for other authen- operating system mechanisms such as protection do- ticating services. We illustrate how separation of priv- mains [11] or application confinement [18, 21, 28]. ileges reduces the amount of OpenSSH code that is ex- However, these solutions do not apply to many exist- ecuted with special privilege. Privilege separation pre- ing applications written in C running on generic Unix vents known security vulnerabilities in prior OpenSSH operating systems. Furthermore, system services that versions including some that were unknown at the time authenticate users are difficult to confine because ex- of its implementation. ecution of privileged operations depends on internal state not known to the sandbox. Instead, this paper discusses the methodology and 1 Introduction design of privilege separation, a generic approach to limit the scope of programming bugs. The basic prin- Services running on computers connected to the In- ciple of privilege separation is to reduce the amount of ternet present a target for adversaries to compromise code that runs with special privilege without affecting their security. This can lead to unauthorized access to or limiting the functionality of the service. This nar- sensitive data or resources. rows the exposure to bugs in code that is executed with Services that require special privilege for their op- privileges. Ideally, the only consequence of an error in eration are critically sensitive. A programming error a privilege separated service is denial of service to the here may allow an adversary to obtain and abuse the adversary himself. special privilege. The principle of separating privileges applies to any The degree of the escalation depends on which priv- privileged service on Unix operating systems. It is es- ileges the adversary is authorized to hold and which pecially useful for system services that grant authenti- privileges can be obtained in a successful attack. For cated users special privilege. Such services are difficult example, a programming error that permits a user to to confine because the internal state of a service is not known to an application confinement system and for proaches to application design that help prevent unan- that reason it cannot restrict operations that the ser- ticipated consequences from such errors: defensive pro- vice might perform for authenticated users. As a result, gramming, language enforced protection, and protec- an adversary who gains unauthorized control over the tion mechanisms supported by the operating system. service may execute the same operations as any authen- The latter two approaches are not applicable to ticated user. With privilege separation, the adversary many Unix-like operating systems because they are de- controls only the unprivileged code path and obtains veloped in the C language which lacks type-safety or no unauthorized privilege. other protection enforcement. Though some systems Privilege separation also facilitates source code au- have started to support non-executable stack pages dits by reducing the amount of code that needs to be which prevent many stack overflows from being ex- inspected intensively. While all source code requires ploitable, even this simple mechanism is not available auditing, the size of code that is most critical to secu- for most Unix platforms. rity decreases. Furthermore, the Unix security model is very coarse In Unix, every process runs within its own protec- grained. Process privileges are organized in a flat tree. tion domain, i.e., the operating system protects the ad- At the root of the tree is the superuser. Its leaves are dress space of a process from manipulation and control the users of the system. The superuser has access to by unrelated users. Using this feature, we accomplish every process, whereas users may not control processes privilege separation by spawning unprivileged children of other users. Privileges that are related to file sys- from a privileged parent. To execute privileged oper- tem access have finer granularity because the system ations, an unprivileged child asks its privileged parent grants access based on the identity of the user and his to execute the operation on behalf of the child. An group memberships. In general, privileged operations adversary who gains control over the child is confined are executed via system calls in the Unix kernel, which in its protection domain and does not gain control over differentiates mainly between the superuser and every- the parent. one else. In this paper, we use OpenSSH as an example of This leaves defensive programming, which attempts a service whose privileges can be separated. We show to prevent errors by checking the integrity of param- that bugs in OpenSSH that led to system compromise eters and data structures at implementation, compile are completely contained by privilege separation. Priv- or run time. For example, defensive programming pre- ilege separation requires small changes to existing code vents buffer overflows by checking that the buffer is and incurs no noticeable performance penalty. large enough to hold the data that is being copied into The rest of the paper is organized as follows. In Sec- it. Improved library interfaces like strlcpy and strlcat tion 2, we discuss the principle of least privilege. We help programmers avoid buffer overflows [17]. introduce the concept of privilege separation in Sec- Nonetheless, for complex applications it is still in- tion 3 and describe a generic implementation for Unix evitable that programming errors remain. Further- operating system platforms. We explain the implemen- more, even the most carefully written application can tation of privilege separation in OpenSSH in Section 4. be affected by third-party libraries and modules that In Section 5, we discuss how privilege separation im- have not been developed with the same stringency. The proves security in OpenSSH. We analyze performance likelihood of bugs is high, and an adversary will try to impact in Section 6. Section 7 describes related work. use those bugs to gain special privilege. Even if the Finally, we conclude in Section 8. principle of least privilege has been followed, an adver- sary may still gain those privileges that are necessary for the application to operate. 2 Least Privilege We refer to a privilege as a security attribute that 3 Privilege Separation is required for certain operations. Privileges are not unique and may be held by multiple entities. This section presents an approach called privilege The motivation for this effort is the principle of least separation that cleaves an application into privileged privilege: every program and every user should oper- and unprivileged parts. Its philosophy is similar to the ate using the least amount of privilege necessary to decomposition found in micro-kernels or in Unix com- complete the job [23]. Applying the principle to appli- mand line tools. Privilege separation is orthogonal to cation design limits unintended damage resulting from other protection mechanisms that an operating system programming errors. Linden [15] suggests three ap- might support, e.g., capabilities or protection domains. We describe an implementation of privilege separation request that allows the child
Recommended publications
  • Least Privilege and Privilege Separation
    CSE 127: Computer Security Least privilege and privilege separation Deian Stefan Slides adopted from John Mitchell, Dan Boneh, and Stefan Savage This week… • How to build secure systems ➤ Least privilege and privilege separation ➤ Sandboxing and isolation • Key is underlying principles not mechanisms ➤ We’re going to look at systems techniques ➤ Other ways to achieve similar goals: language-based Principles of secure design • Principle of least privilege • Privilege separation • Defense in depth ➤ Use more than one security mechanism ➤ Fail securely/closed • Keep it simple Principles of secure design • Principle of least privilege • Privilege separation • Defense in depth ➤ Use more than one security mechanism ➤ Fail securely/closed • Keep it simple Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource Principle of Least Privilege Defn: A system should only have the minimal privileges needed for its intended purposes • What’s a privilege? ➤ Ability to access (e.g., read or write) a resource What’s the problem with this defn? • Talking about a huge, monolith system is not really useful • Why? Network Network User input User device File system File system Breaking a system into components • Compartmentalization and isolation ➤ Separate the system into isolated compartments ➤ Limit interaction between compartments • Why is this more meaningful? Network Network User input User device File system File system How dow we break things apart? Map compartment to user ids! • Recall: permissions in UNIX granted according to UID ➤ A process may access files, network sockets, ….
    [Show full text]
  • New Concept of the Android Keystore Service with Regard to Security and Portability
    University of Bremen Department of Mathematics and Computer Science New concept of the Android keystore service with regard to security and portability. Master’s Thesis by Fritjof Bornebusch reviewed by Dr. Karsten Sohr Prof. Dr. Jan Peleska supervised by Dipl. Inf. Florian Junge 2016 Confirmation I hereby confirm that I wrote this master thesis on my own and that I have used only the indicated references, resources, and aids. In German: Hiermit bestätige ich, dass ich die vorliegende Masterthesis selbstständig verfasst, und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Bremen, 1/13/2016 Fritjof Bornebusch “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler – Bornebusch, Fritjof New concept of the Android keystore service with regard to security and portability. Master’s thesis, Department 3 - Mathematics / Computer Science University of Bremen, 2015 This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). To view a copy of this license, send an email to [email protected], visit http://creativecommons.org/licenses/by-nc-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, California, 94042, USA. Table of Contents Acknowledgements 7 List of Figures 9 List of Listings 10 Acronyms 13 Glossary 15 1 Introduction 19 2 Background 24 2.1 Android System Architecture . 24 2.1.1 Security-Enhanced Linux . 28 2.1.2 Capabilities . 31 2.2 Memory Vulnerabilities . 32 2.2.1 Buffer Overflow Protection . 33 2.2.2 Dead Store Elimination .
    [Show full text]
  • Integration of Security Measures and Techniques in an Operating System (Considering Openbsd As an Example)
    Motivation Security Solutions and Techniques Summary Integration of Security Measures and Techniques in an Operating System (considering OpenBSD as an example) Igor Boehm Institute for Information Processing and Microprocessor Technology Johannes Kepler University Linz, Austria Igor Boehm Integration of Security Measures and Techniques in an OS Motivation Security Solutions and Techniques Summary Outline 1 Motivation The Basic Problem Being Studied Preliminary Solution Ideas and Goals 2 Security Solutions and Techniques Secure Software Design Techniques Memory Protection Techniques Relevance of Random Numbers for Security Igor Boehm Integration of Security Measures and Techniques in an OS Motivation The Basic Problem Being Studied Security Solutions and Techniques Preliminary Solution Ideas and Goals Summary Outline 1 Motivation The Basic Problem Being Studied Preliminary Solution Ideas and Goals 2 Security Solutions and Techniques Secure Software Design Techniques Memory Protection Techniques Relevance of Random Numbers for Security Igor Boehm Integration of Security Measures and Techniques in an OS Motivation The Basic Problem Being Studied Security Solutions and Techniques Preliminary Solution Ideas and Goals Summary The Basic Problem Being Studied The Clever Attacker: . finds a bug . knows how to craft an exploit . the exploit grants the attacker an advantage . the exploit is likely to work on many systems because of the strict regularity of the system environment Is there a way to solve this problem? Igor Boehm Integration of Security
    [Show full text]
  • Z/OS Openssh User's Guide
    z/OS Version 2 Release 4 z/OS OpenSSH User's Guide IBM SC27-6806-40 Note Before using this information and the product it supports, read the information in “Notices” on page 503. This edition applies to Version 2 Release 4 of z/OS (5650-ZOS) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2020-11-16 © Copyright International Business Machines Corporation 2015, 2019. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures................................................................................................................. ix Tables.................................................................................................................. xi About this document...........................................................................................xiii Who should use this document?............................................................................................................... xiii z/OS information........................................................................................................................................xiii Discussion list...................................................................................................................................... xiii How to send your comments to IBM......................................................................xv If you have a technical problem.................................................................................................................xv
    [Show full text]
  • VULNERABLE by DESIGN: MITIGATING DESIGN FLAWS in HARDWARE and SOFTWARE Konoth, R.K
    VU Research Portal VULNERABLE BY DESIGN: MITIGATING DESIGN FLAWS IN HARDWARE AND SOFTWARE Konoth, R.K. 2020 document version Publisher's PDF, also known as Version of record Link to publication in VU Research Portal citation for published version (APA) Konoth, R. K. (2020). VULNERABLE BY DESIGN: MITIGATING DESIGN FLAWS IN HARDWARE AND SOFTWARE. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal ? Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. E-mail address: [email protected] Download date: 07. Oct. 2021 VULNERABLE BY DESIGN: MITIGATING DESIGN FLAWS IN HARDWARE AND SOFTWARE PH.D. THESIS RADHESH KRISHNAN KONOTH VRIJE UNIVERSITEIT AMSTERDAM, 2020 Faculty of Science The research reported in this dissertation was conducted at the Faculty of Science — at the Department of Computer Science — of the Vrije Universiteit Amsterdam This work was supported by the MALPAY consortium, consisting of the Dutch national police, ING, ABN AMRO, Rabobank, Fox-IT, and TNO.
    [Show full text]
  • Mac OS X and Ios Zero- Day Exploit
    Mac OS X and iOS Zero- Day Exploit Security Advisory AE-Advisory 16-08 Criticality High Advisory Released On 28 March 2016 Impact Allows someone to escalate privileges and also to bypass system integrity Solution See the solution section below for mitigation processes. Affected Platforms Mac OS X 10.11.3 and older, iOS 9.2 and older Summary aeCERT has researched and found out about a new threat on Apple Mac OS X and iOS; with the release of OS X El Capitan, Apple introduced a security protection feature to the OS X kernel called System Integrity Protection (SIP). The feature is designed to prevent potentially malicious or bad software from modifying protected files and folders on your Mac. The purpose of SIP is to restrict the root account of OS X devices and limit the actions a root user can perform on protected parts of the system in an effort to reduce the chance of malicious code hijacking a device or performing privilege escalation. However, it has been uncovered a critical vulnerability in both OS X and iOS that allows for local privilege escalation as well as bypasses SIP without karnel exploit impacting all versions to date. Threat Details The zero day vulnerability is a Non-Memory Corruption bug that allows hackers to execute arbitrary code on any targeted machine, perform remote code execution (RCE) or sandbox escapes. The attacker then escalates the malware's privileges to bypass System Integrity Protection SIP, alter system files, and then stay on the infected system. By default, System Integrity Protection or SIP protects these folders: /System.
    [Show full text]
  • Free, Functional, and Secure
    Free, Functional, and Secure Dante Catalfamo What is OpenBSD? Not Linux? ● Unix-like ● Similar layout ● Similar tools ● POSIX ● NOT the same History ● Originated at AT&T, who were unable to compete in the industry (1970s) ● Given to Universities for educational purposes ● Universities improved the code under the BSD license The License The license: ● Retain the copyright notice ● No warranty ● Don’t use the author's name to promote the product History Cont’d ● After 15 years, the partnership ended ● Almost the entire OS had been rewritten ● The university released the (now mostly BSD licensed) code for free History Cont’d ● AT&T launching Unix System Labories (USL) ● Sued UC Berkeley ● Berkeley fought back, claiming the code didn’t belong to AT&T ● 2 year lawsuit ● AT&T lost, and was found guilty of violating the BSD license History Cont’d ● BSD4.4-Lite released ● The only operating system ever released incomplete ● This became the base of FreeBSD and NetBSD, and eventually OpenBSD and MacOS History Cont’d ● Theo DeRaadt ○ Originally a NetBSD developer ○ Forked NetBSD into OpenBSD after disagreement the direction of the project *fork* Innovations W^X ● Pioneered by the OpenBSD project in 3.3 in 2002, strictly enforced in 6.0 ● Memory can either be write or execute, but but both (XOR) ● Similar to PaX Linux kernel extension (developed later) AnonCVS ● First project with a public source tree featuring version control (1995) ● Now an extremely popular model of software development anonymous anonymous anonymous anonymous anonymous IPSec ● First free operating system to implement an IPSec VPN stack Privilege Separation ● First implemented in 3.2 ● Split a program into processes performing different sub-functions ● Now used in almost all privileged programs in OpenBSD like httpd, bgpd, dhcpd, syslog, sndio, etc.
    [Show full text]
  • Make Least Privilege a Right
    Make Least Privilege a Right (Not a Privilege) Maxwell Krohn∗, Petros Efstathopoulosy, Cliff Frey∗, Frans Kaashoek∗, Eddie Kohlery, David Mazieres` z, Robert Morris∗, Michelle Osbornez, Steve VanDeBogarty and David Ziegler∗ ∗MIT yUCLA zNYU [email protected] ABSTRACT ized mandatory access control [17]. The end result is a Though system security would benefit if programmers new operating system called Asbestos. routinely followed the principle of least privilege [24], 2 LESSONS FROM CURRENT SYSTEMS the interfaces exposed by operating systems often stand in the way. We investigate why modern OSes thwart se- Administrators and programmers can achieve POLP by cure programming practices and propose solutions. pushing the features in modern Unix-like operating sys- tems, but only partially, and with important practical 1 INTRODUCTION drawbacks. Though many software developers simultaneously revere 2.1 chrooting or jailing Greedy Applications and ignore the principles of their craft, they reserve spe- cial sanctimony for the principle of least privilege, or Because Unix grants privilege with coarse granularity, POLP [24]. All programmers agree in theory: an applica- many Unix applications acquire more privileges than tion should have the minimal privilege needed to perform they require. These “greedy applications” can be tamed its task. At the very least, five POLP requirements must with the chroot or jail system calls. Both calls con- be followed: (1) split applications into smaller protec- fine applications to jails, areas of the file system that tion domains, or “compartments”; (2) assign exactly the administrators can configure to exclude setuid executa- right privileges to each compartment; (3) engineer com- bles and sensitive files.
    [Show full text]
  • Download the Ethical Hacker's Guide to System Hacking
    The Ethical Hacker's Guide To System Hacking Attacker acquires information through techniques such as foot printing, scanning and enumeration to hack the target system. 1 Footprinting Scanning Enumeration Module Vulnerability Analysis It is the process of accumulating data Vulnerability Assessment is an This is a procedure for identifying This is a method of intrusive probing, Footprinting Scanning System Hacking regarding a specific network environment. active hosts, open ports, and unnecessary through which attackers gather examination of the ability of a system or In this phase, the attacker creates a profile services enabled on ports. Attackers use information such as network user lists, application, including current security CEH concepts of the target organization, obtaining different types of scanning, such as port routing tables, security flaws, and procedures, and controls to with stand 2 information such as its IP address range, scanning network scanning, and simple network protocol data (SNMP) assault. Attackers perform this analysis Methodology Vulnerability namespace and employees. Enumeration vulnerability, scanning of target networks data. to identify security loopholes, in the target Analysis Footprinting eases the process of or systems which help in identifying organization’s network, communication system hacking by revealing its possible vulnerabilities. infrastructure, and end systems. vulnerabilities 3 Clearing Logs Maintaining Access Gaining Access Hacking Stage Escalating Privileges Hacking Stage Gaining Access It involves gaining access to To maintain future system access, After gaining access to the target low-privileged user accounts by To acquire the rights of To bypass access CEH Hacking attackers attempt to avoid recognition system, attackers work to maintain cracking passwords through Goal another user or Goal controls to gain System Hacking by legitimate system users.
    [Show full text]
  • LIBRARIES Building a Global Information Assurance Program.Pdf
    Building a Global Information Assurance Program OTHER AUERBACH PUBLICATIONS The ABCs of IP Addressing Information Security Management Gilbert Held Handbook, 4th Edition, Volume 4 ISBN: 0-8493-1144-6 Harold F. Tipton and Micki Krause, Editors The ABCs of TCP/IP ISBN: 0-8493-1518-2 Gilbert Held Information Security Policies, ISBN: 0-8493-1463-1 Procedures, and Standards: Building an Information Security Guidelines for Effective Information Awareness Program Security Management Mark B. Desman Thomas R. Peltier ISBN: 0-8493-0116-5 ISBN: 0-8493-1137-3 Building a Wireless Office Information Security Risk Analysis Gilbert Held Thomas R. Peltier ISBN: 0-8493-1271-X ISBN: 0-8493-0880-1 The Complete Book of Middleware A Practical Guide to Security Engineering Judith Myerson and Information Assurance ISBN: 0-8493-1272-8 Debra Herrmann ISBN: 0-8493-1163-2 Computer Telephony Integration, 2nd Edition The Privacy Papers: William A. Yarberry, Jr. Managing Technology and Consumers, ISBN: 0-8493-1438-0 Employee, and Legislative Action Rebecca Herold Cyber Crime Investigator’s Field Guide ISBN: 0-8493-1248-5 Bruce Middleton ISBN: 0-8493-1192-6 Secure Internet Practices: Best Practices for Securing Systems in Cyber Forensics: A Field Manual for the Internet and e-Business Age Collecting, Examining, and Preserving Patrick McBride, Jody Patilla, Evidence of Computer Crimes Craig Robinson, Peter Thermos, Albert J. Marcella and Robert S. Greenfield, and Edward P. Moser Editors ISBN: 0-8493-1239-6 ISBN: 0-8493-0955-7 Securing and Controlling Cisco Routers Global Information Warfare: Peter T. Davis How Businesses, Governments, and ISBN: 0-8493-1290-6 Others Achieve Objectives and Attain Competitive Advantages Securing E-Business Applications and Andy Jones, Gerald L.
    [Show full text]
  • Scalar I3 and I6 Open Source Software Licenses
    Tape Automation Scalar i3 & Scalar i6, Firmware Release 1.1 (110G) Open Source Software Licenses Open Source Software (OSS) Licenses for: • Scalar i3 & Scalar i6 Firmware Release 1.1 (110G). The firmware/software contained in the Scalar i3 & Scalar i6 is an aggregate of vendor proprie- tary programs as well as third party programs, including Open Source Software (OSS). Use of OSS is subject to designated license terms and the following OSS license disclosure lists all open source components and applicable licenses that are part of the tape library firmware. All software that is designated as OSS may be copied, distributed, and/or modified in accordance with the terms and conditions of its respective license(s). Additionally, for some OSS you are entitled to obtain the corresponding OSS source files as required by the respective and applicable license terms. While GNU General Public License ("GPL") and GNU Lesser General Public Li- cense ("LGPL") licensed OSS requires that the sources be made available, Quantum makes all tape library firmware integrated OSS source files, whether licensed as GPL, LGPL or otherwise, available upon request. Please refer to the Scalar i3 & Scalar i6 Open Source License CD (part number 3-07787-01) when making such request. For contact information, see Getting More In- formation. LTO tape drives installed in the library may also include OSS components. For a complete list- ing of respective OSS packages and applicable OSS license information included in LTO tape drives, as well as instructions to obtain source files pursuant to applicable license requirements, please reference the Tape Automation disclosure listings under the Open Source Information link at www.quantum.com/support.
    [Show full text]
  • Android Exploits Commanding Higher Price Than Ever Before
    Memo 10/09/2019 - TLP:WHITE Android exploits commanding higher price than ever before Reference: Memo [190910-1] – Version: 1.0 Keywords: Android, iOS, exploit, vulnerability Sources: Zerodium, Google, Wired Key Points The price of android exploits exceeds the price of iOS exploits for the first time This is possibly because Android security is improving over iOS The release of Android 10 is also a likely cause for the price hike Summary Zerodium1, a cyber security exploit broker dealing in zero-day vulnerabilities, has published its most recent price list. It indicates that the price of an Android full-chain exploit with persistence can fetch the developer up to 2,500,000 dollars. The going rate for a similar exploit for Apple’s iOS has gone down by 500,000 dollars and is now worth 2,000,000. This is the first confirmed time when Android exploits are valued more than iOS. Zerodium payouts for mobile devices Up to $2,500,000 Android zero click full compromise chain with persistence. Up to $2,000,000 iOS zero click full compromise chain with persistence. Up to $1,500,000 WhatsApp zero click remote code execution with iMessage remote code execution with local local privilege escalation on iOS or Android. privilege escalation. Up to $1,000,000 WhatsApp remote code execution with local privilege SMS/MMS remote code execution with local escalation on iOS or Android. privilege escalation on iOS or Android. Comments Zero-click exploits do not require interaction from the user. This is very difficult to achieve and thus commands the highest prices.
    [Show full text]