Microsoft won't fix .NET RCE bug affecting slew of enterprise apps, researchers say

Security researchers have revealed a .NET security flaw thought to affect a host of enterprise-grade products that they say Microsoft refuses to fix. Piotr Bazydło, principal vulnerability researcher at watchTowr, unveiled the findings at Black Hat Europe on Wednesday, claiming that several vendor and in-house solutions could …

[Groo The Wanderer - A Canuck]

The obvious solution is for everybody to "fix" Microsoft and their Artificial Ignorance invasion by migrating now to a Linux distribution on the desktop. Unlike Windows 11, there are no "hardware requirements" stopping the vast majority of Windows 10 hardware owners from installing Linux. Some oddball systems may need expert assistance, but all that hardware is old enough that it'll be on the major distribution's supported hardware lists for several years now...

[m4r35n357]

You can at least try experimenting with live USB systems. Give yourself options.

[Sandgrounder]

So your 'solution' to an issue affecting unknown numbers of enterprise server based applications running legacy. Net framework libraries and the ancient Soap framework, is to suggest users switch their desktop client?

Maybe it's me being a bit slow. Perhaps you could explain in really simple terms that a. Net developer may understand exacly how this would resolve the issue for the quoted scenario for an Umbraco CMS for example.

And did I miss the year of the Linux desktop or is that still just around the corner along with fusion power and flying cars?

[Anonymous Coward]

My son is actually working on a fusion reactor, and I was watching Scott Manley flying a Blackfly the other day.

Sadly I can report that I remain the only member of the family using a Linux desktop

[m4r35n357]

Anyone who thinks YOTLD is a good thing hasn't been paying attention over the last couple of decades.

It is currently still in the process of enshittening; there is a way to go before it is done.

[eric79xxl]

Irrelevant

Not a single word you said has anything to with anything in the article, beyond the word Microsoft.

[Groo The Wanderer - A Canuck]

Re: Irrelevant

Because I didn't want to go on an evidence-based rant as to why now is the time - people with functional brain cells are well aware of my arguments in support of Linux (especially Debian 13) over Windows 11 on the desktop. Games were the only reason I used to run Windows, and with the release of 24H2 and the latest from Steam/Proton, Linux now runs more games than a "real" Windows system does!

If that can be achhieved, I have no sympathy for your "enterprise apps." You either wrote them and have the source to fix them, or you have a vendor you probably pay hundreds of thousands a year to support said application.

Either way, your argument doesn't wash.

[Zonker Zoggs]

Re: Irrelevant

The team I work on has inherited a .net framework web API based on WCF. It is potentially vulnerable to this issue.

If I understand you right, if we all upgrade our desktops to Debian 13 - we are golden? This is good news indeed.

[AVee]

Re: Irrelevant

> The team I work on has inherited a .net framework web API based on WCF.

You have my sincere condolences, even if this issue doesn't affect you.

[nijam]

Re: Irrelevant

> The team I work on has inherited a .net framework web API.

How very careless of you. If your gift horse comes from the Microsoft stable, it's too late to look it in the mouth - it's the other end of its digestive system that will be shitting on you.

[localzuk]

Re: Irrelevant

I own a nice sofa. People eat cheese. See how these statements have no relation to each other? That's about as much as your comments about linux on the desktop have in relation to the topic being reported here.

[Anonymous Coward]

Re: Irrelevant

An adequately researched venn diagram would likely show that there is an overlap between people who eat cheese and own a nice sofa.

Further research on what constitutes a nice sofa and if people eat cheese while sat on their nice sofa is required.

[zcomputerwiz]

Re: Irrelevant

Uh huh... I run Linux ( and every other OS ). Everyone else has functional brain cells too - the fact you think everyone is going to uproot their business to move to Linux just displays a lack of experience beyond your own trivial use cases.

Maybe some Linux distro will become a mature desktop OS that can enjoy the same success as Windows, but that can't really happen without a less haphazard design language and user experience, and that would require some more unified direction that isn't really present in today's fragmented open source space ( not to mention the petty quibbling ).

Some of the best things about Linux that make it great for tinkering (endless choices, that it's constantly evolving, doesn't have one set configuration ) are also what hinder it's potential to become *the* mainstream desktop OS.

Maybe Microsoft will build a compatibility layer, run their shell on top of Linux, and make this a moot point. Who knows.

[Anonymous Coward]

Re: Irrelevant

> Maybe some Linux distro will become a mature desktop OS

"Mature" like "straight from 1980"? When was the last time you checked the path length limitation of your OneDrive? Last time I did it was still 255 characters. Mature, indeed!

[Groo The Wanderer - A Canuck]

Re: Irrelevant

Lack of experience? Hardly - I'm retired from a 30+ year programming career, and I didn't buy the excuses while I was working and I don't buy them now. Unless you're STUPID enough to buy into Microsoft's frameworks or a LOCKED IN VENDOR, there is no reason your code shouldn't be migrated. Stupidity, laziness, and incompetence are NOT excuses.

[Alistair Wall]

.NET runs on Linux.

[Anonymous Coward]

You could switch to MacOS and retain the ability to run commercial software, but that's not your core problem here.

The main issue you'll find is that Microsoft spent years ensuring companies were entangled enough to be unable to give up the addiction. That tends to be set in motion by wining and ding the people who do not have the skills to see the stragey but who will take the decisions and then gradually ramming more things based on proprietary mechanisms and standards down their throat as 'features' or 'upgrades' that turning the clokc back becomes impossible and best of breed becomes "only Microsoft". Add to that legal mechanisms so slow they might as well not exist and corrective measures that are flat out laughabale in missing the boat (browser selection, anyone?) and undoing this infection once it has established itself becomes hard, if not impossible, unless someone truly enlightened at the top is able to sell the intermediate disruption to shareholders.

The way to avoid the Microsoft infection is when you start a company and being very, very hard on their inevitable attempts to infect the organisation the moment it starts turning a profit and on executives who let themselves be wined and dined in order to sell the company down the river. After that it becomes too hard - Redmond has been at this for a very long time.

[Paul Herber]

Has anyone tried softsoaping MS?

No? Thought not.

[Anonymous Coward]

Maybe I haven't had enough coffee yet but I need a translation here, sorry.

:)

[Anonymous Coward]

enshittification

[Claptrap314]

That implies a change in the level of sh*t in a vendor's products. I've an all white beard, and I can assure you that this is not the case for this vendor.

[Anonymous Coward]

Touché, Monsieur!

[Doctor Syntax]

"users should avoid consuming untrusted input that could generate and execute code,"

Does Microsoft have a definitive list of ways in which that could happen so that users will know how to avoid them?

[Paul Herber]

<byte value=0..255>

HTH

[nijam]

> users should avoid consuming untrusted input ...

e.g. software from a company that first exploits its customers, then insults them for being exploited.

[Jou (Mxyzptlk)]

The response was bad worded.

The response "users should avoid consuming untrusted input" is the actual bug, which sound to me like calling the developer a user (which is not entirely wrong, but that is another discussion).

I am on Microsoft side, there are valid scenarios for using file:// instead of http(s):// (and various other XXXX://). The application should filter URI prefixes, even if they are encapsulated "WSDL file they control to vulnerable applications, which then generate an HTTP client proxy from it.", because it is still the application executing the encapsulated file://, and not the "user" as TheReg cites MS.

What would happen if MS decides to add an mandatory "AllowFileURI" which is by default $false unless otherwise specified? I don't know...

[NetMage]

Re: The response was bad worded.

Perhaps the object could be updated to require a list of the valid prefixes on every call?

[Jou (Mxyzptlk)]

Re: The response was bad worded.

Huh? Why do it so complex when a simple

-like "https://*"

is enough. Expanded to the number of expected slashes and other details of the expected target path. Any input is not trustworthy by design. Not because someone can hack it, but because it can be faulty.

[Eric 9001]

They can do literally anything and everything and the suckers never say "no more", no matter how many times they get burned.

Unfortunately, you're not allowed to point out what microsoft software has done over and over again (although there is some culpability with hospitals for being insane enough to use microsoft software), as it's considered libel on the register MS (Metal Storm that is).

[ecofeco]

You can't fix cultists.

[An_Old_Dog]

Microsoft's Culpability

is highlighted by the phrase, "the class will ignore the error and then write".

[Bebu sa Ware]

"The neanderthal user should have manually verified the WSDL file"

A bit unfair on our Neanderthal cousins who had the good sense to avoid Windows, Microsoft, computers and pretty much everything else.

I hope they along with the Denisovans hitched a ride with some passing space aliens to a far saner place but the reality is more like they, facing an interminable future with their insane "sapiens" relatives decided to just not bother… a sentiment I can easily understand.

I was wondering what interest the Jehovah's would have in Windows security until I realized Watchtowr was missing the 'e'. I always had the impression the JW would be in the same queue as the Neanderthals waiting for a lift to a better place.

[mcswell]

Re: "The neanderthal user should have manually verified the WSDL file"

The JW expected to be lifted in 1914.

[Anonymous Coward]

Re: "The neanderthal user should have manually verified the WSDL file"

WW1 was just a smoke screen to cover 64000 of them disappearing?

[An_Old_Dog]

Vowel Drop

... I realized Watchtowr was missing the 'e'.

Hmm ... a quick check of the web shows all JW-related-links which I glanced at showing the correct spelling.

Perhaps you saw a one-time printed-version typo.

Perhaps the JWs had contracted an "image consultancy" which recommended they drop the 'e' in "Watchtower" -- until a bunch of older JWs wrote to the head office that the new makeover "makes us look like a bunch of illiterate morons."

[Filippo]

Honestly, this sounds more like a failure of documentation than a bug. Microsoft probably should put a warning where classes that are nearly always used with web URLs actually also accept file URLs.

That said, in order to make bad things happen here, you need to have an application that takes unvalidated user input and makes a call to it. That's fundamentally wrong. There's endless ways that could go be exploitable, and making the SOAP library reject file URLs does not make it "safe" in any way.

[Geoff Campbell]

Always sanitise your inputs

Did little Bobby Tables die in vain?

GJC

[JoeCool]

Yet Microsoft didn't choose that path. They chose "Blame the client" which is deficient in several ways.

[sabroni]

"They soon found that its SOAP API method could be accessed with no authentication"

Ok. I notice the article kind of just skipped past "User didn't set up authentication and authorisation on their endpoint kind of making the rest of the article moot".

Plenty of linux lovers posting that this is MS being evil again though.

So easily manipulated.

I hope you're not on Twitter.

[AVee]

Re: "They soon found that its SOAP API method could be accessed with no authentication"

That's just one example of one situation where this can be exploited in Barracuda Service Center. It's not the core issue here, the root cause it basically that a commonly used .NET class called SoapHttpClientProtocol will happely read and write to local files if it gets a file:// url. And the service discovery logic in SOAP can easily be used to get a file:// url to the client.

So both Baracuda and Microsoft dropped the ball here. But at least Baracuda released a hotfix, Microsoft is refusing to fix anything, claiming that everybody should know that HTTP means 'your local files' or something. Part of me can't blame Microsoft engineers for wanting to run away whenever SOAP or HttpWebRequest is involved (I've got the same reflex), but it's their mess to fix and it's their responsibility to make sure HTTP means HTTP.

[SVD_NL]

Ah right, stupid devs, they should know better!

Barracuda and Ivanti obviously are very small vendors who don't care about security, letting such an obvious bug slip by! I'm sure more mature products and platforms definitely didn;t overlook this very obvious and expected behavior and acted accordingly. /S

[thosrtanner]

I can't help feeling that a class called SoapHttpClientProtocol accepting anything a target that explicitly says not to use Http or Https is a bad idea. Writing to a file is not using http.

So yeah, I sort of agree with the researchers on this one - it should either error or ignore the protocol part - preferably the 1st.

[Geoff Campbell]

HTTP PUT

The HTTP PUT operation is routinely used to write to files, in my experience.

GJC

[heyrick]

Simple answer

Is this local file behaviour documented?

If it is, it's the dev's fault for not reading it, understanding that it could be used for nefarious reasons, and not sanitising inputs (which should always happen, but...).

If it is not documented, then this is 100% on Microsoft for doing weird illogical things and not saying anything, leading to the obvious question of "what else has unexpected features?".

So, which is it to be?

[Claptrap314]

Re: Simple answer

Except that the name IS a kind of documentation. I don't really care what the official documentation says, if you name your function SoapHttpClientProtocol when it can be used for file:// instead of SoapUriClientProtocol, you are deliberately misleading the users of your function.

When I get called in to debug code in some language I've not dealt with before, I don't start by reading the docs end to end. Now, I HAVE, to my great pain, worked with .Net, so I am warned to expect this sort of garbage from Microsoft, but it is still on the function creator to not create functions with clearly misleading names.

[Anonymous Coward]

I'm confused

My system needs to connect to a third party using SOAP. They update their api frequently so I need to go to them get the wsdl. I embded the url of the endpoint in my service and it gives me the WSDL I need to generate a valid request.

If I was writing a system that needed to be able to connect to any SOAP endpoint (though I'm struggling for a use case for this) then I'd need to be fucking sure I verified the url they gave me before I started trying to communicate with them.

So, why do people think this isn't a development issue? The traditional use case doesn't involved dynamic host urls, where's the use case for "send me a link to your wsdl and I'll blindly consume it"? Is it literally just because the class name has HTTP in it? I see that and all responsiblity for checking the source url protocol dissappears?

[Claptrap314]

Re: I'm confused

You are correct that developers should be validating their inputs. But Microsoft is actively misleading the devs, and THAT is the issue raised, and which they are refusing to accept.

[Justin Pasher]

Both sides have a point

This sounds a lot like the protocol handlers in PHP with functions like fopen and file_get_contents. If the allow_url_fopen config option is enabled, you can open remote URLs just like regular files. However, the documentation (at least for fopen) is pretty clear about this functionality. Whether that option should be enabled by default for the sake of convenience is debatable.

Like others have said, it sounds like it might not be clear in the documentation that it supports the file:// scheme. Off the top of my head, I'm not sure when that might be useful for a SOAP request. So, works as intended? I guess. Works in a logical manner? Probably not.

[tiggity]

It's also worth noting that MS helped invent SOAP, & (with a few weird exceptions back in the day e.g. SMTP) it was always promoted as a http(s) protocol (as the method name in the bug strongly suggests!!), When people use framework methods* they do not expect gotchas such as file protocol being supported... and anyone with experience of MS will know their documentation is awful, if I was a betting man I would gamble that the docs for SoapHttpClientProtocol definitely do not emphasise it supports non http(s) endpoints.

* the whole idea of using a framework method from a "big name provider" is that the provider has done a "proper job" and it will be more performant, secure, generally fool proof etc. than "rolling your own" code solution instead. Obviously MS failed badly in this case.