DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Browser Sandboxing: Breaking Out!

Learn more about how browser sandboxing and the major features of the app sandbox attack surface.

Christopher Lamb user avatar by
Christopher Lamb
CORE ·
Jan. 23, 19 · Analysis
Like (3)
Save
Tweet
Share
4.76K Views

Join the DZone community and get the full member experience.

Join For Free

In a few past pieces, I've outlined how the app sandbox and the current version of Seatbelt work on MacOS. I started looking at these two systems because I was interested in how Safari is sandboxed and how you can break out of the sandbox after exploiting Safari itself. Remember, compromising Safari would be only the first step. Safari runs in a kernel-enforced sandbox, and all that compromising Safari could do is give you code execution in a limited process with a controlled environment. To get arbitrary code execution, you need to break out of the sandbox too.

We haven't traced through execution yet, but we know that when a system call is dispatched into the kernel by a sandboxed process, the kernel will check to see if that call is allowed via a hook inserted into the requested system call. If the call is permitted, the hooked call will continue with execution as if the sandbox isn't present. If the call isn't, the call will fail, though the process will generally not terminate.

So what's our attack surface and how can we use it to break out?

Incorrect Policies

The first possible attack vector, once you have control of the sandboxed process, is the policy describing the execution environment. If the policy isn't strict enough, or it contains a bug, we may be able to exploit that bug and escape the sandbox. For example, in a malformed sandbox, it may be possible to, say, spawn a new process without the sandboxing constraints imposed by the parent process. Or, perhaps, you can access a system service, like cron or at, that allows you to schedule a process for later execution, again without the sandbox protections.

Exposed Services

In the previous example, we used services that were exposed by mistake. What about services that are deliberately exposed to the sandboxed process? If that process has access to a system daemon of some kind, say a messaging or mail daemon or a logging system, and that external service has a bug, you may be able to exploit that bug to obtain free system access.

Exposed Files 

What if the policy gives you access to files that are loaded by other, non-sandboxed programs? If so, you can potentially overwrite those files with data you control. You can potentially convince those external applications to do all kinds of things, depending on the program. If that program has a flaw you can exploit, this is another possible avenue for exploitation and access.

Sandbox Services 

Remember, the sandbox itself contains internal services that you can still potentially access after the program is first invoked. Now, most of the work of sandboxing a process happens on program invocation, so if you're attacking a running, previously sandboxed program like Safari, you won't be able to access these call chains. But some of the sandbox services are accessible throughout the process lifecycle. Notably, the sandboxing checks themselves within the kernel and the sandbox logging system hosted by the sandboxed logging and tracing daemon.

That's a quick overview of the major features of the app sandbox attack surface. No matter which attack vector you choose, the existence of the sandbox doubles your work, forcing you to find another exploitable flaw after first compromising Safari. Now, with this outline, we're going to start tracing sandbox execution and beginning to touch on these specific vectors in more detail.

Sandbox (software development)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Exploring the Benefits of Cloud Computing: From IaaS, PaaS, SaaS to Google Cloud, AWS, and Microsoft
  • A Beginner's Guide to Back-End Development
  • Debugging Threads and Asynchronous Code
  • AIOps Being Powered by Robotic Data Automation

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: