Git For Windows Issues Update To Fix Running-Someone-Else's-Code Vulnerability (theregister.com) 12
The Git team has issued an update to fix a bug in Git for Windows that "affects multi-user hardware where untrusted parties have write access to the same hard disk," reports The Register. Specifically, the update is concerned with CVE-2022-24765. From the report: Arguably, if an "untrusted party" has write access to a hard disk, then all bets are off when it comes to the nooks and crannies of a PC anyway. In this case, the miscreants would only need to create the folder c:\.git, "which would be picked up by Git operations run supposedly outside a repository while searching for a Git directory," according to NIST. The result is that Git would use the config in the directory.
NIST went on to list potentially vulnerable products, which included Visual Studio. "Users of the Microsoft fork of Git are vulnerable simply by starting a Git Bash." The Git team was little blunter about the vulnerability, and warned that "Merely having a Git-aware prompt that runs 'git status' (or 'git diff') and navigating to a directory which is supposedly not a Git worktree, or opening such a directory in an editor or IDE such as VS Code or Atom, will potentially run commands defined by that other user." [...] To deal with the issue, the Git team recommends an update. Alternatively, a user could create that .git folder themselves and remove read/write access as workaround or "define or extend 'GIT_CEILING_DIRECTORIES' to cover the parent directory of the user profile," according to NIST.
NIST went on to list potentially vulnerable products, which included Visual Studio. "Users of the Microsoft fork of Git are vulnerable simply by starting a Git Bash." The Git team was little blunter about the vulnerability, and warned that "Merely having a Git-aware prompt that runs 'git status' (or 'git diff') and navigating to a directory which is supposedly not a Git worktree, or opening such a directory in an editor or IDE such as VS Code or Atom, will potentially run commands defined by that other user." [...] To deal with the issue, the Git team recommends an update. Alternatively, a user could create that .git folder themselves and remove read/write access as workaround or "define or extend 'GIT_CEILING_DIRECTORIES' to cover the parent directory of the user profile," according to NIST.
Re: (Score:1)
Re: (Score:1, Insightful)
Re: (Score:2, Informative)
Re: (Score:2)
While XP does use the NT kernel and not DOS, it still has some DOS cruft to make the Windows 98 parts work.
It might help if you said specifically what you're talking about. I could believe there's some DOS code somewhere in the VMs that run such programs. However, ntvdm is only available on 32 bit Windows, and nobody is still running that (and Windows XP was the last version of Windows where you reasonably still had to run the 32 bit version, because XP64 driver support was nonexistent.)
An operating system is not a kernel (Score:2)
Consider the fact that an operating system and a kernel are not the same thing. Especially an operating system the size of Windows.
ntoskrnl.exe is about 10 MB. That's straight from NT. ....
The other few GBs
Consider that for a moment and get back to me.
Re: (Score:1)
Windows still doesn't quite do multi -user securely . . . all of which is designed for a PERSONAL computer, a one-person system.
Windows sucks at multi-user, but there is other stuff that is even more stupid.
A few years ago I suddenly got thrown into the job of administering several PCs (and had no idea what the heck I was doing). Users were deleting files that they shouldn't and in the process of trying to repair things and prevent it from happening, that's when I discovered something truly bizarre. If a file has the "read-only" attribute set, Windows Explorer ignores it and will happily allow you to delete that file.
Yes, th
Re: (Score:2)
I've got bad news for you. That's the standard behavior for POSIX-like file systems. Yes, e