Hacker News Reader

Hacker News

Comment by blueflow | Hacker News Reader

Full thread

blueflow

People who delete system binaries due to whacky CVEs deserve a broken system.

I don't even know who else to blame for this.

View on HN

> I don't even know who else to blame for this.

The people who told them that deleting system binaries would fix their problems?

> I have been pointed to responses on the Microsoft site answers.microsoft.com done by “helpful volunteers” that specifically recommend removing the curl.exe executable as a fix.

Don't trust strangers on the internet with advice you don't understand the implications of. Even if they are sincere and mean well, they can still be wrong.

The problem here is that if they understand the implications they probably would not be on awnsers.microsoft.com in the first place

But that's the problem, the people doing this do not understand what curl is/does so want it gone because its got a CVE and some outlet somewhere has said its worse than what it is.

if that's the case we should just delete the entire OS as there are vulns all over it.

> The people who told them that deleting system binaries would fix their problems?

If you are responsible for the security posture and compliance in your organization, reading and acting on security assessments, and yet you do random changes based on random comments on forums, you deserve the blame.

I don't think we're not talking about individual end-users here. Those do not scan their systems for CVEs and do not have a requirement to get to 0 alerts.

> I don't think we're not talking about individual end-users here.

Are you sure about that? From TFA:

> Lots of Windows users everywhere runs security scanners on their systems with regular intervals in order to verify that their systems are fine. At some point after December 21, 2022, some of these scanners started to detect installations of curl that included the above mentioned CVE. Nessus apparently started this on February 23.

> This is not helpful.

> Lots of Windows users everywhere then started to panic when these security applications warned them about their vulnerable curl.exe.

That sounded like it included individual end-users to me.

Anectodally, I know a few Windows users who don't trust Microsoft to do security well, but can't bring themselves to move off Windows for whatever reason, so run 3rd party AV and security tools to help protect themselves.

The compliance madness I can understand, but for an individual with no legal or management-mandated constraints...

Either you're security-conscious or you do random changes based on anonymous forum posts, I just don't really see an overlap.

In any case, I don't think it's fair to blame the forums for giving you the solution given your whacky requirements.

> Either you're security-conscious or you do random changes based on anonymous forum posts, I just don't really see an overlap.

I think there's going to be a not-totally-insignificant minority of people out there who are both worried about security, but just don't have great technical knowledge. (They sometimes show up on r/privacy if you need convincing they even exist.) Even if it's a really small percentage of users, given how large the Windows install base is, that's still going to be a fair amount of people looking for any kind of fix for the "problem" that their security scanner has warned them about.

> If you are responsible for the security posture and compliance in your organization, reading and acting on security assessments, and yet you do random changes based on random comments on forums, you deserve the blame.

It's not as easy. Of course experienced sysadmins know it's bullshit. The problem is that cybersecurity insurance policies require "immediate action" on alerts and no one, even assuming a competent CTO, wants to be stuck with the bill should a security incident arise and the insurance say "audit says no of your machines had mitigated issue xyz, claim denied". Deleting a flagged binary is evidence of mitigation.

The amount of utter bullshit, not to mention the literal spyware that is insurance-compliant antivirus solutions, that insurances force clients to comply with is insane.

The core problem is that insurances don't have the time to actually do deep dives to check if their clients have decent or no IT security. Hell, I'd wager everyone here knows of "that one server that never got updates, was in no inventory or whatever, and once the last disk failed suddenly everything else came crashing down". And so, insurances go with a 12 pound hammer to which everything is a nail, as it is the best way for them to be able to underwrite policies with the insane amount of coverage that GDPR and friends expose the clients to.

Agreed! And when people like that go to random forums asking for solutions to fix that CVE now, and are told to just override it with latest curl, that is the optimal solution given their (bullshit) constraints and I wouldn't blame the random forums.

I'm guessing a common sequence is someone knowing what curl is, but not knowing that Windows ships with it. So, thinking that System32\curl.exe must have been put there by malware, or put there by someone installing optional software.

Microsoft should have renamed it to WINDLHLP.COM or something Windowsy like that, and none of these people would have dared touch it.

I noticed that "curl" in PowerShell is an alias, so you would have to deliberately say "curl.exe" to get System32\curl.exe

  C:\> alias curl

  CommandType     Name                                               Version    
  Source
  -----------     ----                                               -------    ------
  Alias           curl -> Invoke-WebRequest

That's not the case in the latest versions of powershell.

Yeah they did the same thing with wget. Just absolutely bonkers

That is for Windows Powershell, not Powershell (and yes Windows Powershell is different from PowerShell [1])

curl > curl.exe > C:\Windows\System32\curl.exe

[1] https://learn.microsoft.com/en-us/powershell/scripting/whats...

This is so Microsoft

There are people responsible for the security of Windows systems in some organisations that do not understand their job. They look into their AV solution and it says vulnerable file detected on $x systems and they instruct their IT department to remove the file.

Indeed. Whole companies such as Crowdstrike exist just to sit in between automated tools and heavy-handed action based on tool output.

Ive been actually impressed by Crowdstrike product (I guess)

Ive tested a two or three years old Chrome version with JIT compiler vulnerability and guess what - on empty Linux vm it managed to escape chrome and execute code

Meanwhile on Windows with Crowdstrike Chrome just showed some error message about mem. access

Im not sure who handled that attack - was it Windows or Crowdstrike, but eitherway Ive been impressed

The UK government.

This is a quote from the Cyber Essentials requirements (https://www.ncsc.gov.uk/files/Cyber-Essentials-Requirements-...):

""" The Applicant must be active in its management of computers and network devices. It must routinely

...

remove or disable unnecessary software (including applications, system utilities and network services) """

So, based on the quote above, curl.exe must be removed if it is not used, no matter whether it is vulnerable or not (yes I know it is a misreading, but it's frightening that the most literal interpretation is a misreading).

As mentioned in the article:

>Many Windows users are even contractually “forced” to fix (all) such security warnings within a certain time period or risk bad consequences and penalties.

So the blame would be on managers who think checking boxes is how every single job works.

Many times those managers are not responsible for the contractual obligation either. It's one of those comedy of errors type situations where no one single group is fully responsible but put all the decisions together and bad things result.

> I don't even know who else to blame for this.

Microsoft. It's their binary shipped in their system, and their customers are being directed to break their own systems. It's on them to remediate the situation.

Not really. They aren't the ones directing customers to break their systems. They could ban anti-virus software and get slammed for being anti-competitive I suppose. Or they could try to track down all the vendors who are being stupid and ask them to please stop but that probably won't remediate it. They don't have a lot of moves here nor does the curl project.

Their platform (Windows) is getting a bad reputation due to the problem they neglected to fix (shipping a "vulnerable" curl, informing users when the old curl was getting flagged). They could pass the buck but it's just going to be bad for them later when users think Windows itself has security vulns and breaks itself when the users do what they're told to do by vendors. If they don't want the bad rep, they need to be proactive and work with vendors and better inform customers. If I was the CEO I'd do something about it.

But Microsoft are not advising them to remove curl AFAIK, in that case Microsoft should fix every issue ever within Windows, even if its self inflicted.

End of the day this as Daniel says is scare mongering by others who don't know what they are doing.

The phrase, if someone told you to jump off a cliff, would you?, and, Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should...

How do I know which CVE is wacky and which isn't? Do we need another database for actually-real-CVEs?

Follow the links to the actual issue description and check if it makes sense in your context. While the current aggregators are not perfect, there will always be edge cases where you care about some issues more/less than someone else. The whole idea of having a single number has limitations.

The last couple of CVEs I was forced to address were in docker images based on alpine or debian, in which the some library version on the system was hit with a High or Critical level CVE. But in reality the ability to exploit the vulnerability required being able to execute a particular program on the running system. The levels of exploit required to even get to being able to exploit this vulnerability in the context I was required to mitigate it meant that in reality, your systems have already been compromised even before this can be exploited.

CVE numbers have exploded while their quality has declined partly due to things like company and project bug bounties, where individuals get bonuses internally for submitting CVEs that get an ID. There's a virtual army of people doing nothing but looking for subtle ways to exploit key tools just to be able to earn a bonus. Some bigger projects, like the linux kernel, dispute some CVEs (e.g. CVE-2023-23005) because they are b.s., but smaller projects don't have the luxury.

See the curl maintainer's take on this: https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerab...

They deserve to not be allowed to restore their system to normal?

> The people who deleted or replaced the curl executable noticed that they cannot upgrade because the Windows update procedure detects that the Windows install has been tampered with and it refuses to continue.

This policy makes absolutely no sense.

Since the policy is going an extra mile preventing something rather than simply not caring, it probably does make sense. Just in a way that's not trivial to anticipate.

curl is used to download files… if it is missing, Windows presumably won’t be able to download something. If they just go for it anyway, the system could end up in some undefined state.

I doubt curl is involved in the windows update process itself (seeing as Windows Update is a lot older than the inclusion of curl in Windows)

It does make sense, as the upgrade may break the system because of the tampering. Probably say upfront that there's a problem and let the user do a full reinstall when they can rather than attempt to upgrade and break everything. They could have a "force upgrade" button, but many people would just click that without thinking twice then blame MS when it breaks everything.

Strictly speaking the update process isn't able to update to the new version without the existing file (https://devblogs.microsoft.com/oldnewthing/20200213-00/?p=10...).

As noted on the blog post, the solution is to run the system file checker (sfc) to repair it before running the update

Reply on news.ycombinator.com