Earlier quoted context omitted.
Exactly, yet everyone pretends wasm is the exception for some reason...
I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?
Announcing WCGI: WebAssembly and CGI
101–110 of 121 posts
Re: Announcing WCGI: WebAssembly and CGI
#102Earlier quoted context omitted.
Compiling a service to wasm to protect it "from itself" (ie from untrusted data) has trade-offs. On the one hand, you lose ASLR and other security features designed for native code. On the other hand, your program becomes immune to stack smashing, so arbitrary code execution becomes a lot harder for an attacker (at least that's my understanding).
Does it become harder or easier? #include #include int bad(char* src) { int admin = 0; char buf[2]; strcpy(buf, src); printf("%d\n", admin); return admin; } int main() { if (bad("ADMIN!!!")) { printf("we're admin!\n"); } else { printf("we are not admin\n"); } }
At any rate, the example you give is arguably a better case than what we have right now with JS — anyone interested in subverting client side access policies can poke around trivially in the JS globals, they don’t even need to decompile anything, they have a DOM inspector and a REPL to make exploits that much easier to pull off. If security through obscurity is your thing, compiling to WASM could only help.
Again, though, client side shenanigans shouldn’t be of any concern anyway.
Edit: I thought I was replying to the other comment you made within the context of client side execution, but I can touch on that too.
Programming errors (and resulting exploits) aren’t something unique to WASM, and there’s nothing stopping you from using something like Go or Haskell or Rust as a source language, if you want something more safe than C.
Re: Announcing WCGI: WebAssembly and CGI
#103Earlier quoted context omitted.
Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly
Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.
Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations.
Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either.
The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.
Re: Announcing WCGI: WebAssembly and CGI
#104Earlier quoted context omitted.
Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly
Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with th…
Re: Announcing WCGI: WebAssembly and CGI
#105PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call…
I'm not a fan on the way these features are being tacked back onto the runtime, but the approach of having to opt into them make the security boundary a lot more transparent. By disabling the file system (i.e. baking a fake one into memory) you can prevent whole classes of attacks. You won't get surprised by your logging library making network calls (log4j) if your sandbox never even enabled networking in the first place.
I'd much rather see easy and safe alternatives (like using containerization APIs) but there's still no easy way to tell your computer "run this program with a maximum amount of memory, CPU time, no network access and no file system outside this directory" that doesn't come with tons of caveats for preventing escape. For PHP, setting up a secure systemd configuration (more secure than the one that comes with your package manager) can be done, but it's still far from easy.
Re: Announcing WCGI: WebAssembly and CGI
#106PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call…
Correct - PHP is a scripting language with managed memory, quite different from C. Probably not all, but most WordPress vulnerabilities have to do with issues like sql injection, bad configuration defaults, etc, all in business logic. All of these will continue to exist when compiled to Wasm.
Assuming you actually have access to a database in the first place, while wasmer may have some vendor locked in solutions for it, generally with Wasm you won't get beyond SQLite for the near term.
Re: Announcing WCGI: WebAssembly and CGI
#107Earlier quoted context omitted.
I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless. I can't even come up with a metaphor for it. We're choosing to be stuck with shitty a…
Well, that's partly why WASM exists. It can be run outside a browser, and is much more performant than using the whole browser. The future is very likely going to consolidate around WASM and WebGPU, regardless of what hardware you're targeting. If you want more performant specs, it will be driven through a public and consensus driven way... there are far too many economies of scale to standardization for it not to be…
Largest /s imaginable.
Your comment is pretty far into LARPing territory.
Re: Announcing WCGI: WebAssembly and CGI
#108Earlier quoted context omitted.
http://www.astrodigital.org/space/stshorse.html I'd be very leery of trusting the specifics too much. E.g. the reference to "Roman war chariots", which are not a thing the Romans ever used. Snopes entry: https://www.snopes.com/fact-check/railroad-gauge-chariots/
Nice, so dude was actually just reciting an email FWD he studied to sound interesting. God, I had forgotten about those email FWDs. The old people I know totally abandoned email.
Re: Announcing WCGI: WebAssembly and CGI
#109Earlier quoted context omitted.
Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with th…
> but 20 years ago you could run JVM apps in the browser without issues That was definitely not my experience at that time using a linux desktop.
Re: Announcing WCGI: WebAssembly and CGI
#110Earlier quoted context omitted.
It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.
We are not replicating Oracle’s lawyers, sales agreements and non-disclosure policies.
All angel companies that do no evil.