Microsoft Rolls Back Blocking Office VBA Macros By Default (theverge.com) 33
Microsoft is rolling back a planned change to block Visual Basic for Applications (VBA) macros by default in a variety of Office apps. From a report: Announced earlier this year, Microsoft had been planning to prevent Office users from easily enabling certain content in files downloaded from the internet that include macros, in a move to improve security against malicious files. Microsoft had been testing this change ahead of a planned rollout to all Microsoft 365 users in June, but suddenly reverted the block on June 30th. BleepingComputer reports that Microsoft notified IT admins last week that it was rolling back the VBA macro block based on feedback from Office users testing the changes. "We appreciate the feedback we've received so far, and we're working to make improvements in this experience," reads a Microsoft 365 message. The unusual rollback has surprised some Microsoft 365 users, as many had been waiting years for Microsoft to be more aggressive about blocking macros from Office files. Hackers have been regularly targeting Office documents with malicious macros, and Office has typically prompted users to click to enable macros running with a simple button. Microsoft's planned changes meant Office users would only be able to enable the macros by specifically ticking an unblock option on the properties of a file.
The feedback in question (Score:3)
M$!!! BAD!!11 +387 Insightful (Score:1, Troll)
Everything they do is bad and dumb, even when they do the opposite they've done before, or do something we bitched at them for not doing.
Re: (Score:3)
That's not as contradictory as you think it is. Sometimes doing the thing and the opposite of the thing are equally dumb (and the right thing to do is something completely different). That's what they call a "false dichotomy".
Also, as they say in russian: "whatever a fool does, he does it wrong"
Re: (Score:2)
That's what they call a "false dichotomy".
No.
What happened was... (Score:2)
Paul Allen was in the room when Dilbert's boss called.
The problem isn't macros, but lack of sandboxing. (Score:5, Insightful)
The main problem typically isn't the fact that the macros exist, nor the fact that they can run in documents that you download. The problem is that Microsoft designed their VBA macro system to allow macros from one document to modify the content of a different document, call macros in a different document, etc. This complete lack of proper sandboxing has been the cause of almost all problems with macros over the years, and to date, AFAIK, Microsoft still hasn't fixed that deficiency.
If a document's scripts lacked any access to content in any other document without explicit permission, that would basically eliminate the threat without preventing any legitimate macros, give or take maybe a few ultra-specialized internal document clusters, which could be granted explicit permission, and everything would proceed as if nothing had happened.
But turning off all scripting almost certainly breaks a whole bunch of stuff that shouldn't be broken.
Re:The problem isn't macros, but lack of sandboxin (Score:5, Insightful)
The right thing WAS to design VBA macros securely, but that did not help lock out competitors. As I recall, lots of people made this observation as the time (yes, I am that old).
Re: (Score:2, Interesting)
Indeed. The only real fix at this time is to start over. But with that, competitors (some free, like LibreOffice) stop being a problematic choice, so MS cannot do that either. They really have painted themselves into a corner and I think they have mostly lost control of their products due to technological debt.
Microsoft hates VBA, which is their secret sauce (Score:2)
What's hot and what's not? Not VBA. It uses End If instead of {} which is what all the cool kids use!
But what they miss is that an ordinary non-technical user can and does use VBA to do lots of useful stuff. You can record a macro and run it. No difficult deployment, just put it in the workbook or in a separate add-in workbook. All very simple.
The JavaScript approach they have for web Excel is a disaster by comparison.
Banning VBA bans the reason many people use Excel instead of Google Sheets. Dumb.
As
Re: (Score:2)
The right thing WAS to design VBA macros securely, but that did not help lock out competitors. As I recall, lots of people made this observation as the time (yes, I am that old).
I challenge that. VBA was introduced in 1993, security was basically non-existent, a non-topic for the entire computing industry. General PCs at the time largely had no access control. Even Linux (and Unix) to this day lives with insecure design decisions related to architectural decision that date back to this time (such as the inability to create an effective lock screen on X11).
Now if you want to talk about VBA needing to be fixed, or that people were bitching about it a decade later, I'm right there wit
Re: (Score:2)
On the other hand, there were lots of people who cared a lot about security. There were lots of scripting languages - REXX from IBM started at 1979, Perl started 1988, just to mention two that I used back then. Hell, AppleScript also started 1993 and you don't hear much about their security problems.
As for access control, IBM solved it for MVS and VM/CMS, Mul
Re:The problem isn't macros, but lack of sandboxin (Score:4, Interesting)
Re: (Score:2)
document to modify the content of a different document, call macros in a different document, etc.
Dude that is only the start! If all macros could do was work inside their own documents and with other documents Office new how to handle there would be little if any issue. Reality is they can do arbitrary file I/O, have complete access COM/COM+ and call into libraries with C calling conventions too via imports. Basically anything you could implement in VB6 you can do it pretty directly in an Office VBA macro and the few things you cant are trivially worked around.
complete lack of proper sandboxing
forget the word "proper" there - sandbox
Re: (Score:2)
Yep. Mindless design intended to ass "features" but with no regards to what damage it could do at all. Such an incredible level of stupidity is what I have come to expect from MS though. And given how long they have taken to patch some things in the recent past, my impression is that they slowly lose the ability to "fix" things at all. This is a case of "plan to throw one away, you will anyways", just that we likely have to throw MS away. Well they may survive as a Linux cloud offer, if they do not compromi
Re: (Score:2)
There was no web or internet for most people when VBA was created, back in about 1993.
It is actually very well designed IMHO, the API is excellent.
But yes, it should have been updated with a sand boxed mode some decades ago.
Re: (Score:2)
Yep. That is why we see VBA-based attacks all the time, but rarely see PDF based attacks. Document-to-system, they are not much different.
Re:The problem isn't macros, but lack of sandboxin (Score:4, Interesting)
The problem is not the original design, the problem is their failure to transition their architecture to adapt to new realities. Part of the original objectives for
And the tragedy continues (Score:1)
This is what abysmally bad design gets you: You cannot fix things later because people started to use your messed-up capabilities. We will eventually have to get rid of all that MS crap completely as it cannot be fixed. The pressure to do that is raising.
Re:And the tragedy continues (Score:4, Interesting)
I have been making do with MS Office replacements since 1996. I hate Office with a passion, and I am glad to see its influence on the market become less and less every year. However, I find it hard to consider Microsoft's macro facilities abysmally bad design. After all, it was such a successful design that it allowed Microsoft to maintain its dominance for decades.
Sure, Microsoft would like to undo some of those changes now, as the world has moved away from creating document files and emailing them around, to authoring documents collaboratively on the web. However, there is no question that Microsoft owes a huge portion of its overall success to Office's ability to easily create what are essentially document-based applications. The fact that these applications generally required recent versions of MS Office and MS Windows didn't hurt either. For years this fact guaranteed that serious businesses had to use Windows and MS Office, whether they wanted to or not.
Even now, when Microsoft is desperate to change directions, the design is so successful that even now Microsoft can't afford to turn it off. Too many of the people that haven't already jumped ship to something else are still paying Microsoft for precisely this misfeature.
As I said, I hate MS Office with a white-hot passion, but Microsoft gave customers precisely what they wanted with VBA for Office. Design that people pay money for is the very best sort of design. It has never fit with what I wanted in a document preparation system, but I am quite clearly in the minority.
Re: (Score:1)
but Microsoft gave customers precisely what they wanted with VBA for Office.
And that is what they should not have done. In the security-space, giving people what they want is the road to hell, because people are not security experts and do not understand what the consequences of their wishes are. The only reason for this to backfire so late (but so badly now) is that it took organized crime a lot of time to find a way to monetize this (ransomware payments with crypto-"currencies"). There are some kinds of tools you must never hand to non-experts. Microsoft violated exactly that rul
VBA can't die fast enough (Score:3)
VBA was always a bad idea, it's just that when Microsoft built it, they didn't realize how bad it really was.
In software design, the "single responsibility principle" teaches us that side effects are a bad thing. Each function, each module, each app, should do one and only one "thing." Side effects violate this principle, causing unexpected things to happen, and unexpected things lead to security vulnerabilities. The scope of the "thing" can be higher or lower level, and defining a "thing" can be hard. But there's no doubt that a document editor should not be able to install other software, or browse the web, or change your system settings.
If you want to enable automating document creation, then give Word an API. No problem there. Just don't make Word the development system.
Re: (Score:3)
VBA was always a bad idea
Huh? At the time, it made a lot of sense. It's still a really good idea. The only real problem is security, but that wasn't an issue at all until the internet era.
VBA itself is very easy for non-programmers to learn which greatly enhances the utility of those products. It is an empowering technology. This is a good thing. The whole point of the personal computer revolution was to put the power of the computer into the hands of ordinary people.
In software design, the "single responsibility principle" teaches us that side effects are a bad thing.
What? No. That's not what that's about at all. You're c
Re: (Score:2)
+1.
The whole point is that VBA can be used by a non-professional programmer. No complex deployment etc.
Re: (Score:2)
Yep, and also no source code control, or process control, or code review, or QA, or security review, or deployment control. What could possibly go wrong?
Re: (Score:2)
I won't try to counter each of your points. Clearly, you see the world differently than I do.
It comes down to this. You say VBA makes it "easy" for low-skilled "developers" to make their jobs simpler. I say it's like giving a table saw to a five-year-old. Yes, lots of people did think VBA was a great idea at the time. But I've yet to see a "good" application of the technology, and I've seen a whole lot of bad ones. Many businesses today are forced to relax their security precautions because some guy long ag
Re: (Score:3)
You say VBA makes it "easy" for low-skilled "developers" to make their jobs simpler.
Not quite. I mean people who aren't developers. People who have a need, see a solution, and are ambitious enough to realize it.
Many businesses today are forced to relax their security precautions
The security thing might be more than a little bit overblown. Anything from the internet will still have macros disabled by default and the user will be warned of the potential security risk. What more could you want?
because some guy long ago wrote some embedded VBA script that nobody now knows how it works, but the company somehow depends on it for survival.
"Some guy" who "long ago" wrote that macro understood the problem he was trying to solve and solved it so well that the company has come to rely on it. I fail to s
Re: (Score:2)
No, it's not elitism, it's understanding risks.
Many professions require a license to practice the trade. This mechanism helps to ensure that people are properly trained, both to do the job right, and to avoid risks of catastrophe that might not be obvious to an amateur. This is not condescension, it's managing risk.
Software engineering is the only major engineering discipline that doesn't (yet) require a license. As the discipline develops, and as disasters caused by unqualified programmers unfold, I predic
Re: (Score:2)
That's because programming is nothing at all like engineering. To call programmers engineers is an insult to actual engineers and may even be illegal, depending on your jurisdiction.
As the discipline develops
I'm an old guy. I've been at this a very long time. The discipline is definitely not making progress towards that end. If anything, we've take a few steps backward over the last 25 years or so.
Unblock button (Score:3)
The "Unblock" button is available for ALL files downloaded from the Internet using modern web browsers and email clients. Behind the scenes is a NTFS alternate data stream tied to the file called "Zone.Identifier". The "Unblock" button in the Properties dialog for the file simply deletes that specific data stream. After deleting that data stream, Explorer bypasses SmartScreen checks when opening the file and Office won't complain about it either and just run the macros embedded within. It wouldn't be too difficult to make a little GUI application that a user can drag files onto that removes the "Zone.Identifier" data stream and then runs ShellExecuteEx() with the "open" verb. I'd be very surprised if such a tool doesn't already exist. Browsers on Mac OSX do something similar and then Gatekeeper detects the "downloaded this from the Internet" bit and subsequently sandboxes the application installer.
Re: (Score:2)
My understanding is that they wanted to remove the Unblock button.