<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>linux on Rich Mirch</title>
    <link>https://blog.mirch.io/tags/linux/</link>
    <description>Recent content in linux on Rich Mirch</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 30 Jun 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.mirch.io/tags/linux/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CVE-2025-32462, CVE-2025-32463 Sudo chroot, host Option Elevation of Privilege Vulnerabilities</title>
      <link>https://blog.mirch.io/sudo-elevation-of-privilege-vulnerabilities/</link>
      <pubDate>Mon, 30 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.mirch.io/sudo-elevation-of-privilege-vulnerabilities/</guid>
      <description>&lt;p&gt;I discovered two vulnerabilities in &lt;a href=&#34;https://www.sudo.ws&#34;&gt;Sudo&lt;/a&gt;. Upgrade to Sudo 1.9.17p1 or later.&lt;/p&gt;
&lt;h3 id=&#34;cve-2025-32462---sudo-host-option-elevation-of-privilege-vulnerability&#34;&gt;CVE-2025-32462 - Sudo Host Option Elevation of Privilege Vulnerability&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;a href=&#34;https://www.cve.org/CVERecord?id=CVE-2025-32462&#34;&gt;CVE-2025-32462&lt;/a&gt; has remained unnoticed for over 12 years, despite being present in the code all along. It relies on a specific yet common configuration where Sudo rules are restricted to certain hostnames or hostname patterns. If these conditions are met, privilege escalation to root requires no exploit.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;ul&gt;
&lt;li&gt;Write-up: &lt;a href=&#34;https://www.stratascale.com/resource/cve-2025-32462-sudo-host-option-vulnerability/&#34;&gt;Sudo Host Option Elevation of Privilege&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Advisories
&lt;ul&gt;
&lt;li&gt;Sudo: &lt;a href=&#34;https://www.sudo.ws/security/advisories/host_any/&#34;&gt;https://www.sudo.ws/security/advisories/host_any/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;RedHat: &lt;a href=&#34;https://access.redhat.com/security/cve/cve-2025-32462&#34;&gt;https://access.redhat.com/security/cve/cve-2025-32462&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Ubuntu: &lt;a href=&#34;https://ubuntu.com/security/notices/USN-7604-1&#34;&gt;https://ubuntu.com/security/notices/USN-7604-1&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Debian: &lt;a href=&#34;https://lists.debian.org/debian-security-announce/2025/msg00118.html&#34;&gt;https://lists.debian.org/debian-security-announce/2025/msg00118.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Amazon: &lt;a href=&#34;https://explore.alas.aws.amazon.com/CVE-2025-32462.html&#34;&gt;https://explore.alas.aws.amazon.com/CVE-2025-32462.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Gentoo: &lt;a href=&#34;https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-32462&#34;&gt;https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-32462&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;cve-2025-32463---sudo-chroot-elevation-of-privilege-vulnerability&#34;&gt;CVE-2025-32463 - Sudo chroot Elevation of Privilege Vulnerability&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;a href=&#34;https://www.cve.org/CVERecord?id=CVE-2025-32463&#34;&gt;CVE-2025-32463&lt;/a&gt; The default Sudo configuration is vulnerable. Although the vulnerability involves the Sudo chroot feature, it does not require any Sudo rules to be defined for the user. As a result, any local unprivileged user could potentially escalate privileges to root if a vulnerable version is installed.&lt;/p&gt;
&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>sudoedit symlink fix for CVE-2021-23240 introduced new vulnerability</title>
      <link>https://blog.mirch.io/2021/01/25/sudoedit-lpe/</link>
      <pubDate>Tue, 26 Jan 2021 02:43:51 +0000</pubDate>
      <guid>https://blog.mirch.io/2021/01/25/sudoedit-lpe/</guid>
      <description>&lt;p&gt;I noticed the following changelog entry in sudo &lt;a href=&#34;https://www.sudo.ws/stable.html#1.9.5p1&#34;&gt;1.9.5p1.&lt;/a&gt; This caught my attention so I decided to look further. I was unable to find an advisory, PoC, or CVE for this vulnerability. Using the details from the changelog message and fix, I decided to write an exploit for it.&lt;/p&gt;
&lt;p&gt;&lt;img loading=&#34;lazy&#34; src=&#34;https://blog.mirch.io/images/2021/01/image.png?w=1024&#34;&gt;&lt;/p&gt;
&lt;p&gt;Using an Ubuntu 20.04.1 VM, I created a low privileged user named &amp;ldquo;lowpriv&amp;rdquo; and added a sudoedit rule for a root owned file /etc/test.txt. I also downloaded the &lt;a href=&#34;https://github.com/sudo-project/sudo/archive/SUDO_1_9_5.tar.gz&#34;&gt;source&lt;/a&gt; for sudo 1.9.5, compiled it, and installed it to /opt/sudo.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2019-3466 Debian / Ubuntu Privilege Escalation via pg_ctlcluster</title>
      <link>https://blog.mirch.io/2019/11/15/cve-2019-3466-debian-ubuntu-pg_ctlcluster-privilege-escalation/</link>
      <pubDate>Fri, 15 Nov 2019 12:54:14 +0000</pubDate>
      <guid>https://blog.mirch.io/2019/11/15/cve-2019-3466-debian-ubuntu-pg_ctlcluster-privilege-escalation/</guid>
      <description>&lt;h1 id=&#34;vulnerability-summary&#34;&gt;Vulnerability Summary&lt;/h1&gt;
&lt;p&gt;The &lt;a href=&#34;https://manpages.debian.org/buster/postgresql-common/pg_ctlcluster.1.en.html&#34;&gt;pg_ctlcluster&lt;/a&gt; script in the postgresql-common package in Debian and Ubuntu is vulnerable to a local privilege escalation attack. pg_ctlcluster is a script used to manage PostgreSQL instances. A malicious actor with access to the postgres account can create arbitrary directories during startup or reload when called via systemd. This vulnerability can be leveraged to escalate privileges to root.&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s important to note this is not a vulnerability in PostgreSQL and is specific to Debian, Ubuntu, or any system that consumes the Debian postgresql-common package.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2018-1792 - IBM MQ Privilege Escalation: Fun with RUNPATH</title>
      <link>https://blog.mirch.io/cve-ibm-mq-privilege-escalation-fun-with-runpath/</link>
      <pubDate>Sun, 25 Aug 2019 16:37:18 +0000</pubDate>
      <guid>https://blog.mirch.io/cve-ibm-mq-privilege-escalation-fun-with-runpath/</guid>
      <description>&lt;h1 id=&#34;vulnerability-summary&#34;&gt;Vulnerability Summary&lt;/h1&gt;
&lt;p&gt;&lt;a href=&#34;https://en.wikipedia.org/wiki/IBM_MQ&#34;&gt;IBM MQ&lt;/a&gt; for Linux and UNIX systems is vulnerable to a privilege escalation attack by forcing a setuid root binary to load a malicious library. A local attacker with access to the mqm account can execute arbitrary code as root. In October 2018 IBM published an &lt;a href=&#34;https://www-01.ibm.com/support/docview.wss?uid=ibm10734447&#34;&gt;advisory&lt;/a&gt; along with patches for several versions.&lt;/p&gt;
&lt;p&gt;The goal of this post is to show how the &lt;a href=&#34;https://en.wikipedia.org/wiki/Rpath&#34;&gt;RPATH/RUNPATH&lt;/a&gt; value could potentially be leveraged for privilege escalation. When specified at compile time this path is embedded in the binary and is the first path searched when searching for a library if the dependent library specified does not contain a slash. Details on how this works can be found in the &lt;a href=&#34;http://man7.org/linux/man-pages/man8/ld.so.8.html&#34;&gt;ld.so&lt;/a&gt; man page.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2019-6724 : Barracuda VPN Client Privilege Escalation on Linux and macOS</title>
      <link>https://blog.mirch.io/2019/02/14/cve-2019-6724-barracuda-vpn-client-privilege-escalation-on-linux-and-macos/</link>
      <pubDate>Thu, 14 Feb 2019 15:31:43 +0000</pubDate>
      <guid>https://blog.mirch.io/2019/02/14/cve-2019-6724-barracuda-vpn-client-privilege-escalation-on-linux-and-macos/</guid>
      <description>&lt;p&gt;The barracudavpn component of the Barracuda VPN Client prior to version 5.0.2.7 for Linux, macOS, and OpenBSD runs as a privileged process and can allow an unprivileged local attacker to load a malicious library, resulting in arbitrary code executing as root.&lt;/p&gt;
&lt;p&gt;This post will walk through the process on how I found and exploited the vulnerability on Linux. The full PoC will also work on macOS. When researching for potential vulnerabilities with privileged binaries a test system should be used to avoid causing damage or negative impacts.&lt;/p&gt;
</description>
    </item>
    <item>
      <title>Linux persistence idea - using group passwords</title>
      <link>https://blog.mirch.io/2019/01/09/linux-persistence-idea-using-group-passwords/</link>
      <pubDate>Wed, 09 Jan 2019 18:16:32 +0000</pubDate>
      <guid>https://blog.mirch.io/2019/01/09/linux-persistence-idea-using-group-passwords/</guid>
      <description>A rarely used feature on Linux and UNIX systems is the ability to add a password to a group. The concept is similar to how users are handled. An encrypted hash is stored in the second field of the &lt;a href=&#34;http://man7.org/linux/man-pages/man5/gshadow.5.html&#34;&gt;gshadow(5)&lt;/a&gt; file. Anyone with the password can execute the &lt;a href=&#34;http://man7.org/linux/man-pages/man1/newgrp.1.html&#34;&gt;newgrp(1)&lt;/a&gt; command to temporarily change their GID without having to be a member of the group. The goal of this post is to show how this feature can be leveraged to create persistence on a server in a semi stealthy way.</description>
    </item>
    <item>
      <title>CVE-2018-18629: Keybase Linux privilege escalation</title>
      <link>https://blog.mirch.io/2018/12/21/cve-2018-18629-keybase-linux-privilege-escalation/</link>
      <pubDate>Fri, 21 Dec 2018 18:43:08 +0000</pubDate>
      <guid>https://blog.mirch.io/2018/12/21/cve-2018-18629-keybase-linux-privilege-escalation/</guid>
      <description>&lt;p&gt;Recently I started using &lt;a href=&#34;https://keybase.io/&#34;&gt;Keybase&lt;/a&gt; which is a Slack-like application but provides end-to-end encryption. Version 2.8.0.20181017144746.3efc4cbf3c is vulnerable to a privilege escalation vulnerability allowing a low privileged user to execute arbitrary commands as root.&lt;/p&gt;
&lt;p&gt;After executing the application using a low privileged account I noticed a process named keybase-redirector running as root. I was interested and wanted to understand how this worked. After checking the file permissions I found that the keybase-redirector was setuid root. I enjoy the challenge of finding vulnerabilities in privileged binaries so I started my research.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2018-19788 PoC - polkit: Improper handling of user with uid &amp;gt; INT_MAX leading to authentication bypass</title>
      <link>https://blog.mirch.io/2018/12/09/cve-2018-19788-poc-polkit-improper-handling-of-user-with-uid-int_max-leading-to-authentication-bypass/</link>
      <pubDate>Sun, 09 Dec 2018 19:32:04 +0000</pubDate>
      <guid>https://blog.mirch.io/2018/12/09/cve-2018-19788-poc-polkit-improper-handling-of-user-with-uid-int_max-leading-to-authentication-bypass/</guid>
      <description>&lt;p&gt;While reviewing my Twitter feed I noticed a recent popular tweet from &lt;a href=&#34;https://twitter.com/0xdea&#34;&gt;@0xdea&lt;/a&gt;.
&lt;a href=&#34;https://twitter.com/0xdea/status/1070308598146850818&#34;&gt;https://twitter.com/0xdea/status/1070308598146850818&lt;/a&gt;
I was intrigued and wanted to see if there was a way to leverage this to execute arbitrary code as root.&lt;/p&gt;
&lt;p&gt;First we need to understand what the value of INT_MAX is. Fortunately the getconf command can be used to find the value or you can find it in /usr/include/limits.h.&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;o&#34;&gt;[&lt;/span&gt;root@localhost ~&lt;span class=&#34;o&#34;&gt;]&lt;/span&gt;&lt;span class=&#34;c1&#34;&gt;# getconf INT_MAX&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;m&#34;&gt;2147483647&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;o&#34;&gt;[&lt;/span&gt;root@localhost ~&lt;span class=&#34;o&#34;&gt;]&lt;/span&gt;&lt;span class=&#34;c1&#34;&gt;# grep &amp;#39;define INT_MAX&amp;#39; /usr/include/limits.h&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;c1&#34;&gt;# define INT_MAX 2147483647&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;To exploit the vulnerability the user must have a UID value larger than 2147483647. I used the same value of 4000000000 that &lt;a href=&#34;https://twitter.com/0xdea&#34;&gt;@0xdea&lt;/a&gt; posted.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2018-18556 - VyOS Privilege escalation via sudo pppd for operator users</title>
      <link>https://blog.mirch.io/2018/11/05/cve-2018-18556-vyos-privilege-escalation-via-sudo-pppd-for-operator-users/</link>
      <pubDate>Tue, 06 Nov 2018 04:39:42 +0000</pubDate>
      <guid>https://blog.mirch.io/2018/11/05/cve-2018-18556-vyos-privilege-escalation-via-sudo-pppd-for-operator-users/</guid>
      <description>&lt;p&gt;Recently I found several ways to escape the restricted shell for an operator user in &lt;a href=&#34;https://wiki.vyos.net/wiki/User_Guide&#34;&gt;VyOS&lt;/a&gt; 1.1.8. VyOS is a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. I plan to post information on the restricted shell escapes in the near future; For now read the &lt;a href=&#34;http://blog.vyos.net/the-operator-level-is-proved-insecure-and-will-be-removed-in-the-next-releases&#34;&gt;blog&lt;/a&gt; by &lt;a href=&#34;https://x.com/dmbaturin&#34;&gt;@dmbaturin&lt;/a&gt; detailing some of the methods.&lt;/p&gt;
&lt;p&gt;This post will focus on how root access was obtained using sudo after the restricted shell was escaped. One of my first post exploitation steps on Linux after a low privileged shell is obtained is to check if the user has sudo rules configured. Sudo is designed to limit privileges but often it can be leveraged to elevate access.&lt;/p&gt;
</description>
    </item>
  </channel>
</rss>
