VBScript is in a .vbs file and run from the command line. There are still lots of tools in office and windows that use this like the command line licensing tools olk.vbs and slmgr.vbs so this is an odd security over functionality decision.
Excel macros are written in this by fortunate decisions in the article below, not sure if the windows cscript and wscript tools that execute vbs have dependency ties to excel https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
like outlook does to the word editor dlls.
I'd be fascinated to learn what a previous employer will do with all the vbscripts I wrote on Windows XP to drive various things of theirs. They have to maintain things for 20 to 30 years and they are basically snapshots in time. When I was there in the mid 00s they still had a Windows 95 test bench that ran software that only worked there. So I guess there's my answer: they'll keep the Win XP boxes around as long as they need to.
Yes, vbscript is the default scripting language for windows. Many viruses have been spread because .vbs files were set to auto-run: https://en.m.wikipedia.org/wiki/ILOVEYOU
Yeah, this article doesn’t do a great job of disambiguating among VBA (in Excel, Word, etc. and probably sticking around), VBScript in the browser (in Explorer, defunct), and desktop scripting VBScript (now deprecated). The Wikipedia articles for VBA and VBScript seem to suggest that VBA is an embedded implementation of Visual Basic (pre .Net) whereas VBScript is a separate scripting language with similar syntax and features.
VBS is basically VBA without any of the typing/early binding, i.e. everything is a Variant.
I seem to recall a couple of other pesky nuances.
One thing I thought was a win decades ago in the ASP/pre-jQuery days was being able to tell where the code would execute based upon language.vVBSsript on the server; JS in the browser.
Possibly. They both run through the same scripting host and share other plumbing.
The article makes very little mention of server-side use, just “Windows client” other than one quote.
Classic ASP is included with Windows Server 2022 so IIRC by the standard rules MS follows for server products it won't be fully deprecated there until some time in 2031, and that will include VBScript and JScript.
I can buy the "wmic will be ripped out" but this is hard to believe. So many corporate crap depends on vbs. Not only that, random programs, installers/uninstallers and more lazily use it. This was the thing you used in windows before powershell was a thing (this and jscript). You can maybe use mshta but it too can't do much without vbs/js code.
I'll give you an example: most hp printer setup crap uses mshta which if I remember right uses vbs code (could be jscript too). I assume since the windows script host supports both, this would affect jscript as well.
I know it is the actual title of the article, but is "ripped" really an accurate word to use to describe what is happening here?
> "VBScript is being deprecated," Microsoft said. "In future releases of Windows, VBScript will be available as a feature on demand before its removal from the operating system."
This sounds like the opposite of "ripped" to me. Maybe "slowly withdrawn" might be more accurate.
"Ripped" implies (to me) a sudden and traumatic removal, without care for collateral damage that might be caused.
I am a VBS user and am not particularly happy about this. Wish it could just remain, but I guess I kinda I understand why it's being removed. Honestly I'll probably be off Windows by the time it's totally gone so it's probably fine.
Honestly I'm surprised it lasted this long if anything. Windows scripting moved over to powershell like a decade ago at this point (if not more). I imagine it's only Microsoft's strong commitment to backwards compatibility which has let VBS last this long.
Welcome to The Register, the on-line newspaper that has been calling people who write Wikipedia "wiki-wankers" and "wiki-fiddlers" since 2004, and named Kevin Warwick "Captain Cyborg". There is a reason that it has a red masthead. (-:
VBScript was how I got into programming well over a decade ago, was reading a book on vista where there was a short chapter on automating some file operations etc. I still remember the excitement of typing the commands into notepad and seeing a modal popup saying Hello World!. I made a monstrous text adventure game by just copy pasting and modifying hundreds of if statements where you could "branch" off an have entire new adventures and if you didn't like it you could come back to the original, little to no idea how it all worked but it kept working until it didn't.
I'm a bit nostalgic about this. Not because of VBScript or even JScript. But because of ActiveState which provided Perl, TCP, and Python interpreters that worked with Windows Script Host. I could create and call COM interfaces plus the CPAN library to pick from. I built Tkinter GUIs for my scripts.
It was part of the OLE dream that users would have lots of small scripts automating their component-oriented workflows. What we got instead was cargo-cult coding and innumerable vulnerabilities because, to borrow a phrase from the IoT folks, the 'S' in COM/OLE stands for security.
With process-sandboxed WASM in modern browsers, you can call into whatever you can compile into WASM from JS. emscripten-forge hosts WASM packages built from conda-forge -like recipes installable at runtime with micropip in pyodide in e.g. JupyterLite and vscode.
There's no scripting MS Agents like Peedy and Bonzai Buddy from VBScript, but there are now a bunch of W3C-standardized APIs with varying levels of browser implementations catalogued at MDN and caniuse; WebSockets, WebRTC, WebUSB, WebBluetooth, WebGPU, WebNN, File System Access API: https://developer.mozilla.org/en-US/docs/Web/API/File_System...
Yeah, but some new tech became very relevant over time.
Examples include Unicode in NT 3.5, asynchronous I/O in NT 4, multi-CPU support in Win2k (become mainstream after hyperthreading and especially multicore CPUs), 3D GPU for desktop compositor in Vista (people universally hated the hardware requirement, but over time we got pretty fast 3D GPUs even inside low-end processors).
Sadly, it seems they stopped implementing awesome new stuff after Windows 7.
VBScript was such an underrated way to write exploits for IE users. You could have programs run that could make web requests with cookies and process page data. When I did this pen test back in the day I found forum software that had HTML enabled in the signature field. I wanted to show that you could turn something as simple as XSS into really high-level access. So I ended up writing a program that did this:
Payload: change a users signature to the program and hide the code on the edit page
Vectors:
- VScript - submit a request with the users cookies on IE (also defeats client-side CSRF tokens)
- Phispher - use javascript to show a phisphing page for the login screen as the signature code runs (works cross-browser but requires interaction.)
- PHP - collect forum logins and send requests to update signatures with the program
Results:
I ended up spreading to most signatures in the forum, undetected. Ended up gaining access to all the forum admin users. From there is was easy to get a shell on the forum because there were theme uploads via the admin page. Called a reverse shell via perl -> nc with the www-data user and then privilege escalation with a local exploit to get root.
... but VBScript was still pivotal to spreading the code because IE was very wide-spread back then (and very, very vulnerable.) Good times / 10.
20 years ago, I got into programming by writing little VBScript extensions for my StarCraft clan’s bot on battle.net. It was primitive, but such a fun and social way to get into programming!
This news made me trawl through the Wayback Machine to find my first blog I wrote in classic ASP using VBscript with an Access database. This was back in 2003! "We've caught on to the latest craze on the internet - the Blog (web log) - where we'll be able to post regular updates of what's going on in our lives." I had photo albums, a calendar view, and the obligatory guest book (with no authentication of course). All developed with VBscript and Windows Notepad. :-)
Later in my sysadmin life, I wrote massive logon scripts, printer deployment tools, computer auditing scripts, and much more with VBscript. It was a surprisingly capable scripting language. Later we learned how to add a nice GUI to the scripts using HTA which added an HTML front end using Internet Explorer.
Having written utility scripts embedded into my installer using VBScript, I am not amused. It used to be that MS was known for going to great lengths to achieve backward compatibility, but now even they are infected with CADT programmers.
My only hope is that some BigCOs scream loud enough about MS breaking all their old stuff.
47 comments
[ 1.7 ms ] story [ 79.2 ms ] threadExcel macros are written in this by fortunate decisions in the article below, not sure if the windows cscript and wscript tools that execute vbs have dependency ties to excel https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev... like outlook does to the word editor dlls.
Anything that can be virtualized should be virtualized.
I doubt if they'll ever be able to remove VBA. Way too much legacy code... the customers would mutiny.
I seem to recall a couple of other pesky nuances.
One thing I thought was a win decades ago in the ASP/pre-jQuery days was being able to tell where the code would execute based upon language.vVBSsript on the server; JS in the browser.
JS seems like an out-of-body experience as it is.
The article makes very little mention of server-side use, just “Windows client” other than one quote.
Classic ASP is included with Windows Server 2022 so IIRC by the standard rules MS follows for server products it won't be fully deprecated there until some time in 2031, and that will include VBScript and JScript.
I'll give you an example: most hp printer setup crap uses mshta which if I remember right uses vbs code (could be jscript too). I assume since the windows script host supports both, this would affect jscript as well.
> "VBScript is being deprecated," Microsoft said. "In future releases of Windows, VBScript will be available as a feature on demand before its removal from the operating system."
This sounds like the opposite of "ripped" to me. Maybe "slowly withdrawn" might be more accurate.
"Ripped" implies (to me) a sudden and traumatic removal, without care for collateral damage that might be caused.
https://learn.microsoft.com/en-us/windows/whats-new/deprecat...
It was part of the OLE dream that users would have lots of small scripts automating their component-oriented workflows. What we got instead was cargo-cult coding and innumerable vulnerabilities because, to borrow a phrase from the IoT folks, the 'S' in COM/OLE stands for security.
There's no scripting MS Agents like Peedy and Bonzai Buddy from VBScript, but there are now a bunch of W3C-standardized APIs with varying levels of browser implementations catalogued at MDN and caniuse; WebSockets, WebRTC, WebUSB, WebBluetooth, WebGPU, WebNN, File System Access API: https://developer.mozilla.org/en-US/docs/Web/API/File_System...
From "Manifest V3, webRequest, and ad blockers" (2022) https://news.ycombinator.com/item?id=32953286 :
> What are some ideas for UI Visual Affordances to solve for bad UX due to slow browser tabs and extensions?
> - [ ] UBY: Browsers: Strobe the tab or extension button when it's beyond (configurable) resource usage thresholds
> - [ ] UBY: Browsers: Vary the {color, size, fill} of the tabs according to their relative resource utilization
> - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU, RAM, Disk, [GPU, TPU, QPU] (Linux: cgroups,)
MS had the technology which used HTML for GUI: https://en.wikipedia.org/wiki/HTML_Application
Interestingly, it arrived in IE5 in 1999, almost 15 years before the very first version of Electron.
Examples include Unicode in NT 3.5, asynchronous I/O in NT 4, multi-CPU support in Win2k (become mainstream after hyperthreading and especially multicore CPUs), 3D GPU for desktop compositor in Vista (people universally hated the hardware requirement, but over time we got pretty fast 3D GPUs even inside low-end processors).
Sadly, it seems they stopped implementing awesome new stuff after Windows 7.
Payload: change a users signature to the program and hide the code on the edit page
Vectors:
- VScript - submit a request with the users cookies on IE (also defeats client-side CSRF tokens)
- Phispher - use javascript to show a phisphing page for the login screen as the signature code runs (works cross-browser but requires interaction.)
- PHP - collect forum logins and send requests to update signatures with the program
Results: I ended up spreading to most signatures in the forum, undetected. Ended up gaining access to all the forum admin users. From there is was easy to get a shell on the forum because there were theme uploads via the admin page. Called a reverse shell via perl -> nc with the www-data user and then privilege escalation with a local exploit to get root.
... but VBScript was still pivotal to spreading the code because IE was very wide-spread back then (and very, very vulnerable.) Good times / 10.
Do you mean phishing? I searched for "Phispher" thinking it might be a particular tool or something, but nothing turned up.
Later in my sysadmin life, I wrote massive logon scripts, printer deployment tools, computer auditing scripts, and much more with VBscript. It was a surprisingly capable scripting language. Later we learned how to add a nice GUI to the scripts using HTA which added an HTML front end using Internet Explorer.
My only hope is that some BigCOs scream loud enough about MS breaking all their old stuff.