An attack that confuses security tooling into an insecure action. So, what is dependabot, if you’ve used GitHub you’ve probably seen it around. Its a bot that scans a projects dependencies and when applicable it’ll automatically create a PR to bump versions up to newer releases.

One interesting feature of this is that if you set a dependencies to a specific git repository in order to make use of currently unreleased changes dependabot can detect when those changes get released in a public package and automatically send a PR to convert your dependency from git to the package again. The problem lies in how it does this detection, and important how it handles projects that are not supposed to have a public package at all.

Well it takes the name of the git-repository and treats that as the package name. If it finds a package with the same name it assumes they are the same, so it checks the commit you have in the dependency, and then goes to the package, retrieves the repository information and commit for its latest release. Then using the repository from the public package, checks that the first commit is included in the commit history of the release. If so it’ll create a PR bumping the version to use the public package.

This means an attacker, who can guess or otherwise disclose a peivate dependency using a git repo can get Dependabot to incorrectly produce a PR to point the dependency towards a malicious package.

A post by Ophion Security that looks at customer support portals built off Zendesk that have poor configuration such as GitHub. Zendesk supports “placeholders” for tickets, mainly for support agents and automated responses to use for autofilling information, such as the ticket ID, someone’s name, etc. Because this is of course enticing as an attack surface, Zendesk has two separate APIs for ticket handling. The requests API is the less privileged one, and is what customer support portals should use, while the tickets API is an admin API and can use placeholders. It turns out that many of the support portals they looked at that were built off Zendesk incorrectly used the tickets API. This can allow untrusted users access to placeholders, which in some cases can allow exfiltrating private information.

Case study: GitHub GitHub was one such vendor that had this misconfiguration. As a bot was responsible for managing the ticket on Zendesk and essentially proxies the ticket, one attack that’s possible is exfil’ing the bot’s user info. Perhaps more impactful is the ability to CC other users onto the ticket and get access to their respective user objects, which can allow an attacker to dump their email, name, roles, and other fields.

A linux kernel bug in the overlayfs filesystem that can lead to root privilege escalation. For a bit of background, overlayfs allows you to have a filesystem that’s comprised of two layers; an upper layer and a lower layer. Any changes on files that exist in the lower layer effectively gets that file “copied-up” into the upper layer, which will reflect the file changes on the overlay filesystem without changing the lower layers’ version of the file. This seems fairly straightforward until you consider that the upper and lower directories might be mounted under different user namespaces.

By creating a lower directory in a user namespace, an attacker can effectively use their fake root privileges to create a root-owned setuid binary. By subsequently triggering a copy-up of that file into the upper directory (which can be some world-writable directory such as /tmp), they can get their crafted setuid binary copied and treated as a real root-owned setuid binary, which can then be used to easily run attacker-controlled code as root.

The fix for this was to not allow copying up files from the lower layer to the upper layer unless the file owner had a user mapping in the lower namespace. In this attack scenario, the user namespace would have root mapped to the lower-privileged user instead of itself, and so the copy-up is denied.

Two vulnerabilities in Parallels Desktop, a plist injection and a Time-of-Check Time-of-Use (TOCTOU) race.

Vuln 1: XML injection in Shared Applications The first vuln has to do with Parallel’s support for “Shared Applications”, which allows you to have a guest application displayed on the host’s mac dock or launchpad and similarly be able to launch the application in the guest this way. To facilitate this, parallels will monitor the guest and send (untrusted) toolgate requests to the host, which a driver then processes to create “helper apps”. Various fields from the request end up stored in the XML property list (plist). While most fields were sanitized against XML injection, the URL scheme and file extensions weren’t. This allows you to break out of the XML and inject arbitrary properties, including LSEnvironment for defining environment variables for app launches. By setting the DYLD_INSERT_LIBRARIES to a directory with attacker-controlled files, code execution can be achieved.

Vuln 2: TOCTOU in Shared Folders While the first vuln can achieve code execution, it’s tricky to exploit on its own as you need to be able to write some malicious file on the host to be read as a dynamic library. This is where the second vuln comes in via Shared Folders, which allows the guest to send instructions to the host to perform operations on the filesystem in a given shared directory. While it tries to ensure accesses from the guest are contained to the shared folder, it has the classic issue of TOCTOU when handling symlinks. By racing the check, you can get an arbitrary file write outside the shared folder and chain with the first bug for code execution on the host.