Ask Slashdot: Does WebAssembly Increase Your Web Browser's Attack Surface? - Sl...
source link: https://developers.slashdot.org/story/22/07/16/0450218/ask-slashdot-does-webassembly-increase-your-web-browsers-attack-surface
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Ask Slashdot: Does WebAssembly Increase Your Web Browser's Attack Surface?
Catch up on stories from the past week (and beyond) at the Slashdot story archive
binspamdupenotthebestofftopicslownewsdaystalestupid freshfunnyinsightfulinterestingmaybe offtopicflamebaittrollredundantoverrated insightfulinterestinginformativefunnyunderrated descriptive typodupeerror
Steve Springett is a conscientious senior security architect. And in 2018, he published an essay on GitHub arguing that from a security engineer's perspective, WebAssembly "increases the attack surface of any browser that supports it."
Springett wrote that WebAssembly modules are sent in (unsigned) binary format — without a transport-layer security mechanism — and rely on browser sandboxing for safety. But the binary format makes it harder to analyze the code, while sandboxing "is prone to breakouts and effectiveness varies largely by implementation. Adobe Flash is an example of a technology that was sandboxed after a series of exploits, yet exploits and breakouts still occurred." Springett even went so far as to offer the commands for switching off WebAssembly in your browser.
Now Tablizer (Slashdot reader #95,088) wants to know what other Slashdot readers think of Spingett's security concrens around WebAssembly.
And also offers this suggestion to browser makers:
Browsers should have a way to easily disable WebAssembly — including whitelisting. For example, if you need it for specific gaming site, you can whitelist just that site and not have WASM exposed for other sites.
Do you have a GitHub project? Now you can sync your releases automatically with SourceForge and take advantage of both platforms.
Do you have a GitHub project? Now you can automatically sync your releases to SourceForge & take advantage of both platforms. The GitHub Import Tool allows you to quickly & easily import your GitHub project repos, releases, issues, & wiki to SourceForge with a few clicks. Then your future releases will be synced to SourceForge automatically. Your project will reach over 35 million more people per month and you’ll get detailed download statistics.
Sync Now
-
›
-
Agreed. Complexity increases the attack surface.
-
Just another pile of "whee! lookit us!1!" code, as everything else in this browser/webbertube space.
The real question is: Has anyone realised this?
To which the answer is, yes, everyone not stupid. But that's the same set of people who both have the requisite insight into piles of code and who generally stay well away from diddling with "'web".
Put another way, "How have the people involved not realised this?"
The people who do diddle with "'web" either have corporate interests and don't care, or are enamo
-
-
From the perspective of responsiveness and performance I can understand the speculative execution but for the perspective of power efficiency it's not that good.
Speculative execution is also of course a potential risk of a security issue, but it will require in-depth knowledge to utilize it in a meaningful way.
-
-
-
-
The standard first post for something like this is:
Betteridge's Law
-
Yes but so what. Will Intel and AMD CPUs be canned because of the features enabling Spectre? That's the job of computer science to make new things and make them secure. The usefulness pros of webasm outweighs the increase in attack surface cons thousands to one
-
-
... did developers not notice the last 23 years of PC game theft, and the evils of mainframe computing and client-server executables?
To complain about web assembly in a world of steam, world of warcraft and locked down android and mobile devices like iphone, web assembly is the least of your worries. The thing that should actually worry us - is the death of local applications, because by defintion if you have any client-server app you don't own the device or application.
So any steam/uplay/mmo/f2p app can literally harvest your data because you don't have the source to see what valve/and the rest of the software and hardware industry is harvesting from your PC.
I'm sure many of these developers have a copy of steam and windows 10, I've seen developers almost proud they are using malware like windows 10 and 11. Either way the battle for privacy and security was lost because the average person on our planet simply keeps buying client-server infested exe's with drm and encryption.
-
-
Dude you are an idiot, when I mean "client server" I mean a program who which is note entirely running locally on your PC and is using the network cable as a dongle for missing files and game code, mmo's were just a rebranding of PC games so they could steal them and prevent piracy, they are litearlly just PC games with missing networking code, the plethora of server emulators for ultima online and wow should put to death any idea that they rerquired user names, login accounts, and magical networking code t
-
-
And you missed the enitre context of the OP story, what was the OP complaining about, the large attack surface, now considering the topic you're being a total fucking tool. The tool was about web assembly leading to large attack surface in browers, not getting that ANY client-server program like steam, mmo's, windows 10, iphone IOS, and android have HUGE attack surfaces, so why would web assembly be anything when people are willingly taking up software that has constant open ports?
You are really a jackass
-
-
-
You're right about client-server.
Signing code, so you know who wrote it, isn't a bad thing. in fact a significant percentage of the time people try to run malicious code in my company, they mistakenly think they are running something from a trusted source.
Having the code signed so I can tell whether it's actually an original DLL from Microsoft or an original driver from Ubuntu is a *good* thing for security.
I've been a security professional for 25 years. I have a couple degrees in the field. Last week I spo
-
And for being a security professional it really doesn't matter because the masses have taken up windows 10 and steam, and the fact you're falling into the trap that was sprung by big media companies, they are changing how exe's and files will be issued over the next coming decades, and ou will always be permanently identifiable with TPM keys on your PC. So no more anonymity for you on the internet (IP addresses give reasonable doubt, hardware encrypted identifiers will always id your PC the same, regardless
-
-
-
Nice whaddaboutism! Let me see if I can one-up you: why worry about controlling your compute environment when youâ(TM)re certain to die anyway? You should be focused on cancer cures *instead of* computer security issues.
Did I do it right?
-
Man, you really don't grasp how companies operate, companies only want "Security" for drm and harvesting data from users (aka so they can engage in malfeasance and get away with).
It's not what aboutism, companies want you always online (aka PC games, mobile, etc) for ads, engagement and data, their interests are at odds with a geninely secure computer that allows you to block stuff, lie to google and have control over your PC. Like we had with CPU's from the 60's until the mid 2000's and early 2010's (inte
-
-
Sorry but no. That issue long predates anything to do with games, and is largely not resolved with any open source either. There is practically no one out there with the skills and capability to independently audit all the code running on their PC. Fuck just the audit on OpenSSL, and the audit on Truecrypt took teams of people over a year to complete.
I'll show you some source, you'll download it without understanding it, compile it and hope I'm trustworthy. Nothing more. Hell I bet you won't even do that, I
-
-
Every line of code potentially increases anything's attack surface.
Even if WebAssembly's design is completely secure, implementations will never be.
WebAssembly is just the standardization of things that Javascript VMs have been doing, or moving towards. If people don't use WebAssembly, they'll still use Javascript, which is not immune from security issues either. Especially with the NPM nonsense where people just blindly depend on any unverified code.-
Wasm is somehow worse though...
-
WebAssembly is just the standardization of things that Javascript VMs have been doing, or moving towards. If people don't use WebAssembly
Are any browsers running Javascript on top of WASM? Then at least you just have one implementation to try and keep secure, instead of a WASM implementation and a separate Javascript native JIT...
-
-
... your browsers black box rich client capabilities and I think we can all agree that that is generally a bad thing if you let the general public and dimwitt webagency deciders do too much with wasm in the client.
I personally find transpilation to wasm useful for fancy stuff like live 3D in modern browsers, special effects or some low-level utility stuff like cryptography.
Other than that I'd stear clear of wasm. It's not needed if you know what your doing. And if you don't... well, see above.And as a very experienced web deceloper with 20+ years of projects under his belt I'm _very_ sceptical of anyone betting the farm on deeply wasm-centric solutions such as MS Blazor and similar tech-lock-down hacks and proprietary b*llsh*t.
-
> I personally find transpilation to wasm useful for fancy...
The appropriate word here is "compilation".
-
The appropriate word here is "compilation".
Transpiling to wasm and then compiling to bytecode is the procedure.
The relevant part being transpilation, because the least of people will be writing wasm by hand.
Especially not in those toolchains we're talking about. Emphaiszing that this is yet another part of the webdev camp that is prone to inner platform bloat is appropriate. Ergo: "Transpiling" is the term.
-
-
-
MinaInerz (Slashdot reader #25,726) thinks that WebAssembly isn't any more-or-less secure than Javascript. It's clearly the direction that the web is heading, and if you're that concerned about WebAssembly you should probably disable Javascript, images, videos, stylesheets, certificate parsing, and network requests.
-
Exactly. WASM does not really give you much more than JS attack-wise.
-
-
WebAssembly relies on hardware virtualization for isolation, as does most package managers now (windows store, play store, iOS app store, snap, etc). So I would argue that the major problem with Wasm is a trust interface. the app stores offer more oversight and sign apps. I think what could make wasm better would be more advanced version of let's encrypt which offer transparency and accountability of publishers of applications via free, public, open sourced, mechanisms.
-
An attack surface is merely a section of code. Therefore, if code (in this case) for handling WebAssembly is added to your existing code base then by definition it increases the attack surface. Some code is more dangerous than others, for example, parsers are exceptionally dangerous because they are directly accessible via input.
WebAssembly presents a fairly unique opportunity as languages can be compiled to WebAssembly and nobody has to bother dealing with Javascript. This means large binary blobs will be generated (because compilers) and we have no immediate way of discerning their function. Even minified JS was possible to read but this isn't the case with WebAssembly.
-
FTP protocol: we must remove it after 28 years because the 50 lines of code required to implement it widen the browser's attack surface.
Automatic machine language translator that runs remote code with free access to the GPU and no questions asked: OK, let's do this!
-
In the case of FTP, the argument makes sense. Because FTP is a plaintext protocol, it's trivial to perform man-in-the-middle attacks against it.
Lots of other people have pointed out in this thread that Web Assembly is not obviously worse than, say, JavaScript in terms of attack surface. Wasn at least has a good theoretical basis for its security model. Any rich client interface will have security concerns based on the native APIs it exposes.
-
Being plaintext has nothing to do with the ability to perform man-in-the-middle attacks. Encryption is for privacy, not for authentication. And man-in-the-middle attacks are not really that trivial to perform. Getting a free and anonymous TLS certificate, on the other hand, is trivial.
Code written in C is intrinsically more dangerous than JavaScript code, because C's memory model comes with a whole range of bugs that JavaScript doesn't allow. And being able to remotely generate and execute specific machine
-
Which commonly used plaintext protocols support strong (e.g. replay-proof) authentication?
Wasm isn't just compiling C and running it on the client. I'm not sure why you are talking like it is.
-
-
No, the argument doesn't make sense. There are both mechanisms for secure authentication and secure data transfer for FTP. The death of FTP was simply that it wasn't hip enough anymore.
-
No browser has ever supported them. FTP support in the browser was only ever a half-baked kludge.
-
-
-
FTP wasn't removed because of the browser attack surface. It was removed because it had no fucking business being in the browser in the first place. It was a kludge we fixed by making HTTP transfer reliable and resumable 20 years ago. It's removal was rightly in line with a general attack on any protocol that sends authentication over plain text.
WebAssembly adds capability to the browser that browsers benefit from. FTP in the browser only served to fuck up the FTP protocol as it was never properly supported
-
-
(Former Mozilla Distinguished Engineer here FWIW.)
Parsing WebAssembly modules does represent a small increase in attack surface, and there is additional attack surface if the browser has a dedicated WASM interpreter or JIT compiler. But in Firefox, for example, the WASM optimizing compiler uses the same Ionmonkey infrastructure as the JS engine so there isn't much new attack surface in that JIT compiler. That is very different from say Flash which had its own entirely different compiler.
WASM applications use the same browser APIs as JS does, so there is no new attack surface there. That's a big deal and one of the benefits of WASM's design over say (P)NaCl.
Overall, yeah, WASM adds some attack surface, but not much compared to the rest of the browser. And it's all contained in the sandboxed renderer process(es).
-
Exactly. Essentially you get a bit of complexity increase which comes with a bit of attack surface increase, but that is it. There is essentially nothing new that could not have been done in JS before. Some timing-based attacks may be more efficient in WASM than in JS, due to higher speed, but they were already possible in JS.
-
If we can be comparative for a second, rather than absolute, wouldn't you say that the WASM compiler has a lower potential attack surface than the entire JS engine, just due to the lower complexity?
I am assuming that the sandbox risk is invariant between the two.
I believe the OP is worried that WASM represents a larger attack surface than JS when perhaps he should prefer JS.
Of course "both" may be theoretically greater, at an ecosystem level, the more the industry moves towards WASM the greater our security
-
- when perhaps he should prefer JS.
+ when perhaps he should prefer JASM.
-
-
-
goto: about:config [about]
set: javascript.options.asmjs to false
set: javascript.options.wasm* to false
set: security.csp.wasm-unsafe-eval.enabled to false-
Please someone mod this man up. This is the only practical post worth its weight in salt in this whole discussion.
-
-
Two years ago, security researchers found that more than half of web sites that used WebAssembly used it to mine cryptocurrency in visitors' browsers. Another use of WebAssembly was for obfuscating malvertising. Many of those web sites had been hacked.
In my view, those were, and still are good reasons for having WebAssembly disabled in the web browser by default.
(Link to archived article without infinite scroll [archive.org], Discussion [slashdot.org])I think that WebAssembly's future instead is on the server and maybe even on the desktop. Not only is it an architecture-neutral, language-neutral software distribution format (with more promise than ANDF ever had), but instances can be started with much low overhead compared to containers.
There are also some research OS:es that use it for regular programs: One approach I've seen discussed is to use a safe programming language such as Rust for the main system but WebAssembly sandboxes for other languages.-
Oh please no. Why is it whenever a language has a horrible track record in the client we should then move it to the server? We have plenty of good server side languages and frameworks. They are far better than the nonsense that runs on the clients. If it isn't good enough for the client, it definitely isn't good enough for the server where the requirements are much harder. NodeJS is a terrible, terrible idea and is only liked by "full-stack" engineers who write non-scalable and non-secure websites for
-
Not really. Just because nefarious actors got onto something to make it popular doesn't mean functionality needs to be disabled. It means it needs to be made manageable.
-
-
A browser's attack surface is already huge and JavaScript is quite enough to access all of it. Sure, some timing-based attacks may be a little easier to exploit using WASM, but that should essentially be it. The bit about "analyzing the code" is pretty much nonsense, you can obfuscate JS just as well (so source code does not help) and automatic analysis is pretty infeasible at this time except for really simple things. Same for "transport layer security".
All in all, browsers are not really getting any less
-
WebAssembly modules are sent in (unsigned) binary format — without a transport-layer security mechanism — and rely on browser sandboxing for safety
How does javascript compare to WebAssembly modules in these respects? Unsigned javascript code runs constantly in the browser, and TLS is not mandatory (although in practice HTTP/2 forces it, both for javascript and WebAssembly). The only difference is the binary format then; but obfuscated javascript code and WebAssembly modules are both difficult to
-
Web Attack Surface Module
-
has been a joke since some bright spark decided a program designed to render HTML pages should also be able to execute random code blindly pulled off the internet. WebAssembly is just the latest nail in that particular coffin.
-
Apple is preparing a new feature for iOS16 for the ultra-paranoid (and those who better be ultra-paranoid) named lockdown. One feature is no JIT compilation for JavaScript. You lose an enormous amount of speed but it reduces the attack surface.
The conclusion is that web assembly increases your attack surface. The question is how paranoid you have to be to turn it off.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK