Conversation

Notices

1. Embed this notice
   Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 10-Apr-2025 01:48:33 JST Will Dormann

   After installing April's updates, Windows 10 and 11 systems now have an empty C:\inetpub directory.

   This seems... unexpected?

   • Embed this notice
     Kevin Beaumont (gossithedog@cyberplace.social)'s status on Thursday, 10-Apr-2025 01:48:33 JST Kevin Beaumont

     in reply to

     @wdormann since anybody can create a folder on the root on C:, that might actually be exploitable before the patch is installed

   • Embed this notice
     Kevin Beaumont (gossithedog@cyberplace.social)'s status on Thursday, 10-Apr-2025 17:16:57 JST Kevin Beaumont

     in reply to

     • Jernej Simončič �

     @jernej__s @wdormann that’s also an exploitable vulnerability, a standard user shouldn’t be able to stop a security update installing

   • Embed this notice
     Jernej Simončič � (jernej__s@infosec.exchange)'s status on Thursday, 10-Apr-2025 17:16:58 JST Jernej Simončič �

     in reply to

     • Kevin Beaumont

     @GossiTheDog @wdormann At least it looks like the update fails to apply if you create a file named inetpub in root first.

   • Embed this notice
     cy (cy@fedicy.us.to)'s status on Thursday, 10-Apr-2025 23:53:19 JST cy

     in reply to

     • Kevin Beaumont
     Seems odd to call it an exploit to create "C:\inetpub" when being able to create a folder on the root on C: shouldn't be possible in the first place.
     
     CC: @wdormann@infosec.exchange
     
   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 11-Apr-2025 00:39:02 JST Will Dormann

     in reply to

     • Kevin Beaumont
     • Fritz Adalis
     • Jernej Simončič �

     @FritzAdalis @GossiTheDog @jernej__s
     If IIS is truly installed, KB5057589 installs fine.
     Presumably the failed installation is due to unexpected permissions on C:\inetpub?

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 11-Apr-2025 00:39:03 JST Will Dormann

     in reply to

     • Kevin Beaumont
     • Jernej Simončič �

     @GossiTheDog @jernej__s
     Yeah, so this is interesting. I was skeptical, but I can confirm that KB5057589 (which installs KB5055674) for Windows 10 will fail to install if there is a C:\inetpub directory present ahead of time, which a non-admin user can fulfill.

     I wouldn't expect the update to be so fragile that the mere presence of a C:\inetpub directory prevents its installation. While KB5057589 is indeed listed as a "Security Update", I can find no information of what CVE(s) it fixes. 🤔

   • Embed this notice
     Fritz Adalis (fritzadalis@infosec.exchange)'s status on Friday, 11-Apr-2025 00:39:03 JST Fritz Adalis

     in reply to

     • Kevin Beaumont
     • Jernej Simončič �

     @wdormann @GossiTheDog @jernej__s
     I wonder if it'll fail to install if iis is actually present, or present but moved to another drive.

   • Embed this notice
     faebudo (faebudo@ioc.exchange)'s status on Friday, 11-Apr-2025 01:12:19 JST faebudo

     • Kevin Beaumont
     • Fritz Adalis
     • Jernej Simončič �

     @GossiTheDog @wdormann @FritzAdalis @jernej__s There are now sites that say that you can safely delete the folder after installation of the kb.

     My assumption is that the folder has been created to fix a possible vulnerability where a user can place a folder/file there to exploit a bug in another component and elevate privileges. I would leave it there.

   • Embed this notice
     faebudo (faebudo@ioc.exchange)'s status on Friday, 11-Apr-2025 01:18:34 JST faebudo

     • Kevin Beaumont
     • Fritz Adalis
     • Jernej Simončič �

     @GossiTheDog @wdormann @FritzAdalis @jernej__s Yes it opens a new one. But does the created folder by the update still allow a user to create files in C:\inetpub or are the permissions locked down to administrators?

   • Embed this notice
     Jernej Simončič � (jernej__s@infosec.exchange)'s status on Friday, 11-Apr-2025 03:21:49 JST Jernej Simončič �

     • Kevin Beaumont
     • Fritz Adalis

     @GossiTheDog @wdormann @FritzAdalis I just tested, and while you can create inetpub folder without elevation, you can't create an inetpub file, so you at least can't prevent the update from installing as a regular user.

   • Embed this notice
     faebudo (faebudo@ioc.exchange)'s status on Monday, 14-Apr-2025 18:55:06 JST faebudo

     in reply to

     • Kevin Beaumont
     • Fritz Adalis
     • Jernej Simončič �

     @GossiTheDog @wdormann @FritzAdalis @jernej__s
     So the update fixes CVE-2025-21204 by updating folder permissions for C:\inetpub even if it was created by a user beforehand. Also a normal user can't create files in C:\ only folders.

     https://www.windowslatest.com/2025/04/11/windows-11-microsoft-warns-do-not-delete-inetpub-folder-after-causing-confusion/

     Users that already deleted the folder should temporarily install IIS to create the folder again with correct permissions.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Monday, 14-Apr-2025 20:55:09 JST Will Dormann

     • Kevin Beaumont
     • Fritz Adalis
     • Jernej Simončič �
     • faebudo

     @GossiTheDog @faebudo @FritzAdalis @jernej__s
     If I remember my testing properly, a junction to a folder does not break the update. But a weird junction to a file (which Microsoft claims is not possible) does break the April update.

     Which mirrors the test that a C:\inetpub directory does not break the update but a C:\inetpub file does break things. Except that the junction variant is something a non-admin user can do.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 17-Apr-2025 22:53:55 JST Will Dormann

     in reply to

     From over at the Bad Site ™
     Both the vulnerability and the "fix" for CVE-2025-21204 are quite silly.

     The scenario is:

     1. Non-admin user creates C:\inetpub\wwwroot directory and puts web content there
     2. Admin user at some point in the future enables IIS on the system.

     The outcome is:
     The web content provided by the non-admin user (be it a web shell or whatnot) is served up by IIS.

     Maybe non-admin users shouldn't be able to make directories or junctions (to directories or files) in C:\?
     NAH.

     Maybe installing IIS should provide a clean webroot when it's installed?
     NAH.

     Just preemptively make a C:\inetpub directory that non-admin users can't write to. That fixes the problem. 🤦♂️

   • Embed this notice
     Kevin Beaumont (gossithedog@cyberplace.social)'s status on Thursday, 17-Apr-2025 22:53:55 JST Kevin Beaumont

     in reply to

     @wdormann MSRC still haven't triaged the (I think) vuln CVE-2025-21204 patches introduces 🤪

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 17-Apr-2025 22:53:56 JST Will Dormann

     in reply to

     So, apparently this is the "fix" for CVE-2025-21204. Microsoft recently updated their advisory to say what the update does.

     Prior to everybody freaking out, the advisory for CVE-2025-21204 said nothing about what it does.

     Two gripes:

     1. MSRC publishing content-free advisories has consequences, but they never seem to appreciate this.
     2. I told MSRC YEARS AGO that they can avoid an entire class of LPE vulnerabilities in 3rd-party software and their own software by not allowing non-admin users to be able to create directories off of C:\. They refused to make any change because it might "break things".

     Great job, folks.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Thursday, 17-Apr-2025 22:53:56 JST Will Dormann

     in reply to

     Would changing the ACLs to not allow non-admin users the ability to create directories off of C:\ really have a real-world impact of limiting LPEs?

     Absolutely. When you write a tool to look for things (e.g. Crassus), you see things. Heck, I've seen a privileged service attempt to open files in C:\Program%20Files\, which any non-admin Windows user can create by default.

     But no, even despite being presented with evidence for how this could fix an entire CLASS of LPEs on Windows, MSRC was not interested.