Microsoft script recreates shortcuts deleted by bad Defender ASR rule
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
The U publishing code their parrot could have written under the noses of the Kernel Team makes it clear that anyone with COMMIT status could do so. Anyone.
You can say that about anything. But the reality is, that that's not true. That ANYONE can PROPOSE something bad has nothing to do with source licensing. That's the first piece. And that anyone could sneak something under their noses is a theory that they proved wrong. Yet Defenser ASR proved correct.
But in neither case is the availability of teh source a factor. But in the open source example there is vastly more chances to catch someone having done that. Vastly more.
In closed source, there can be no trust.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
There's a big difference there as that ANYONE could be a lot more than what should be a closed loop supply chain.
So again...
- That the supply chain is open or closed is misleading. Open source doesn't imply that the supply chain is open or even visible. Nor does closed source suggest that the supply chain isn't open.
- In this case, the supply chain IS closed, just like Windows Defender ASR.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
In both cases, there has been a demonstrated failure to test their code prior to publishing and to operate under a zero trust paradigm.
No, neither case demonstrates that. That's not even what the researchers were attempting to test. They were attempting to test human error, not an existence of trust.
And they got caught, while it wasn't as soon as we'd hope, it happened. No different than a bad employee getting fired at Microsoft. The difference is that one is public and open to inspection and discussion. The other is closed and secret. Which process should you trust? You can't say the secret one, we know that that isn't the answer.
I'm literally dealing with this with a closed source financial systems vendor. We can't see their code, but we can see how it is interacting with the database and were able to tell the financial operator that they'd been intentionally putting a lot of holes (hypocrite commits) into the system. And since it is closed source, we don't know how many, when, who, etc. It's all hidden from us. They conveniently "lost" the code commits so that they can't tell us any details. but what we know is that really bad things, not just research, was happening.
With open source we'd at least have a guarantee that we could look into it. With closed source, we have to start over with another vendor. This is all internal, so we aren't talking public open source, but source open to the customer, but the effect is the same. Malicious updates going in and using the closed source aspect to hide it.
We think at least SOME of the employees that did it were fired. Because of that? We'll never know. It's all secret. But one thing we know.... we can't trust anyone there.
The issue here is that we are just looking at human error. No one accepted the Linux commits on purpose, they didn't see the mistakes. No one put the bad update on ASR on purpose, they didn't see the mistake.
We can feel really, really sure that Microsoft tested the f out of that code and just didn't catch the cases or way that it did this weird shortcut delete. And we know for a fact that the Linux kernel gets insane testing before release AND after release by primary AND third parties.
So it's not showing a lack of testing, or an abundance of trust. It's showing the risk of human error when something bad happens that can be hard to catch or test for. You can only test for things you can predict.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
Neither are perfect but when it comes to the balance of "trust" I think closed source has the edge.
I think a key error here is the "no one is perfect" attempt. That's not true. Closed source is full of problems. Every aspect of closed source is bad for customers.
On the other hand, open source is perfect. Literally every aspect of it is perfect for customers.
Neither system, perfect licensing or terrible licensing, protects against anything outside of the realm of licensing. But that doesn't make the licensing good or bad. Those are other things.
My company makes both closed AND open source software. But the quality of the two are essentially the same. Same people, same tools, same workflow, same supply chain. None of that is the licensing.
The open source products have customer benefits that the closed source ones do not.
Think of licensing like french fries. If a burger joint produces terrible fries, it can still make great burgers. If a burger joint produces the perfect, best ever french fry, it could still have an awful hamburger.
That the french fries are good or bad doesn't change the potential for doing unrelated things good or bad. But any meal with perfect french fries will be equal or better than any meal with terrible french fries, all other things being equal.
That is like licensing. Open is always better. Always, there can't be an exception. Any differences that make individual software better or worse are caused by other factors.
While open is always better, period, that simple fact is often totally misunderstood and taken to mean that that one tiny aspect of things is significant. It is not. Source licensing plays a pretty trivial role in the quality of products. That people concern themselves with source licensing instead of designing, making, maintaining, supporting, or selecting quality software is insane. Open source provides for some ability to have trust in a system that otherwise you have to take blindly on someone's word. If you are concerned about "zero trust".... well, only open source allows for a zero trust system in IT. So if that's something you promote, you literally rule closed source out right there, black and white. Closed source depends on trusting a system designed to obfuscate your security blindly - the opposite of zero trust, a total trust system.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
@scottalanmiller said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
Is OSS any better? Nope.
https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source
In fact, a very big NOPE.What? It's SO much better. And you provide a famous reference as to why it is better.
Huh?
The U published code under the noses of the Kernel Team with not a peep out of the KT until the U pointed out that they did it?
Seriously?
Yes, but they at least published what went wrong on all sides. Because the process is open, because the patches are open. Will Microsoft do the same? Even if they did, could we trust it? No, and of course not.
Open source encourages accountability. Closed source eliminates accountability.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
No Feelings here Scott just thoughts.
The reason I think it is feelings is that this is an issue about what we assume is an honest mistake by a closed source development team and the issue is in no way caused by it being closed, simply a mistake was made.
You then took an example of something that went wrong, but was ultimately handled well by an open source team, but everything that went wrong was with a malicious use of an open submission mechanism and nothing to do with the source being open, and used it to say that open source was also negative. You had an old example locked and loaded to post that wasn't caused by the source being open in any way, but by something else (open submission and human error.) Something that, for all we know, happened with ASR (but unlikely, but we'll never actually know.)
None of the things that happened in the OP were licensing related, and nothing in the Linux example were licensing related... but you used both to set up an attempt to discredit open source. That feels like a super emotional reaction. What made you even think about something so disconnected to try to disparage in this thread? Logically there is no connection.
The one thing that I can think of is that it is easy to say that the ASR problem would have had more chance of being caught and more chance of getting accountability if it had been open. But just open source isn't enough to overcome most problems, it's only a minor improvement. I can only imagine that you felt that people would quickly realize that Windows patches, being closed source, carry more risk so you went on an offensive about something that you felt could undermine open source - not by showing it to be worse, only showing it to not be a panacea, which is a common manner of emotional manipulation we often see used by vendors to convince IT departments to "avoid improvement unless the improvement leads to perfection." It's an odd thing that I don't understand why humans think that "better isn't better", but it's a common sales tactic that works.
That's why I felt your response was an emotional one.
-
@scottalanmiller Wow, what a set of responses.
The elephant in the room: The U got code committed to the kernel. It could have been anything and no one would be none the wiser.
Assumption is the mother of all f*ckups and anything but the above statement that is stating the obvious is superfluous. Period.
But please, continue to try justifying the results and the behaviour of the Kernel Team.
Just an FYI: It won't wash with me.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
The elephant in the room: The U got code committed to the kernel. It could have been anything and no one would be none the wiser.
I get why it might seem that way. And yes, there is a potential for that to be true. But we certainly don't know that it is true. What we KNOW is that attempts were made to hide some bugs in code that made it through a review and testing process.
Would other things have made it through? We don't know. Did these get through because they were super sneaky or because the process is super lax? We don't know.
The only real difference here is that we know how the one was submitted, we don't know how the MS code is submitted, but there might be public portals to that as well. We don't know what controls they have. We don't know that there is testing or review.
Any risk that we can think of that we find on the Linux kernel may exist in Windows, too. All of them.
But again, it's an elephant about something other than being open source. Did bad things happen? Yes. Were they related to being open source? Obviously not. They were related to some combination of that specific projects decisions around submission and review.
-
@PhlipElder said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
But please, continue to try justifying the results and the behaviour of the Kernel Team.
Just an FYI: It won't wash with me.You are attempting to deflect the point. The point was you are doing two things here...
- Trying to deflect blame from a current, and common, Microsoft problem by cherry picking a single historic incidence somewhere and....
- Incorrectly taking an isolate failure in a supply chain and applying it to something wholly unrelated and resulting in a completely illogical conclusion because there's no connection between the issue and your result.
I'm don't have to justify the kernel team having missed some bugs, because no one catches all bugs. There's nothing to justify.
The question is, why are you trying to vilify the entire concept of code review and openness, especially when none of that was involved in the issue, let alone was the issue an... issue.
-
@scottalanmiller said in Microsoft script recreates shortcuts deleted by bad Defender ASR rule:
The question is, why are you trying to vilify the entire concept of code review and openness, especially when none of that was involved in the issue, let alone was the issue an... issue.
He must think it's not possible or less likely for closed source to contain bugs, bad code, or malicious actors, and that if it does they would catch and disclose it more openly and better? Unsure of the logic there.
