daniellehmann (u/daniellehmann)

daniellehmann commented on CPython's main branch running in the browser with WebAssembly twitter.com/ethanhs/statu... · Posted by u/bobbiechen

AkshitGarg · 4 years ago

Yep you need to specify the maximum memory amount up-front. Its defined as "webassembly memory pages". Each page is 64kb. You need to specify an initial and a maximum amount. The webassembly module can call memory.grow() to grow it by a page until it reaches the maximum. Though you can't "un-grow" or decrease the amount of allocated memory.

daniellehmann · 4 years ago

This is not correct, it is not necessary to specify a maximum memory size. See the WebAssembly specification https://webassembly.github.io/spec/core/syntax/modules.html#.... Due to 32-bit address space, the maximum memory is limited to 4GB however.

(In asm.js, memory was provided by an ArrayBuffer of fixed size, so there memory could truly not grow at runtime.)

daniellehmann commented on Better Operator Precedence scattered-thoughts.net/wr... · Posted by u/kelseyfrog

superlopuh · 4 years ago

Yes:

    precedencegroup MyPrecedence {}
    infix operator +++: MyPrecedence
    func +++ (lhs: Int, rhs: Int) -> Int { lhs + rhs }
    let a = 1 + 2 +++ 3

Error:

    Adjacent operators are in unordered precedence groups 'AdditionPrecedence' and 'MyPrecedence'

daniellehmann · 4 years ago

Very cool, thanks a lot for the example!

daniellehmann commented on Better Operator Precedence scattered-thoughts.net/wr... · Posted by u/kelseyfrog

userbinator · 4 years ago

because the precedence rules of arithmetic are familiar to most people.

It's not obvious to most people what precedence to expect

Nothing is obvious to anyone who hasn't learned it yet. Where do you draw the line? The rules of a natural language are orders of magnitude more complex, yet humans have no problem learning and using them. There are twenty-six letters in the English alphabet, and "most people" wouldn't have trouble answering if C comes before or after J. Yet you look at the few more levels of precedence in this other language you use nearly every day, and "OMG too hard!!!!11" ?

It's sad to see this strange sentiment of "anti-intellectualism" or "anti-learning" that seems to be slowly growing in the programming community; and turning a linear one-dimensional ranking into a two-dimensional sparse matrix of comparisons seems like the exact opposite of a solution or reduction in complexity.

daniellehmann · 4 years ago

My reading of the article is not that it promotes "anti-intellectualism" or that it argues to remove all implicit precedence or associativity rules.

I think it actually gives a nuanced answer to your question "where do you draw the line", namely: With a partial precedence scheme, one does not need explicit parentheses for those operator combinations for which the precedence is "clear enough". E.g., in "3 + 2 * 4" precedence is clear to virtually all programmers because it follows standard rules from math ("PEMDAS"), so that is why the precedence table in the post specifies an ordering. However, especially for operators which are less frequently used, or where precedence does differ between languages, one should give parentheses for clarity. I think this is a very sensible argument.

I have certainly made errors because of unclear precedence (e.g., with boolean operators, exponentiation, casting etc.) in the past. And given that there even is a CWE number (https://cwe.mitre.org/data/definitions/783.html) for this kind of error, it seems frequent enough to warrant discussion.

daniellehmann commented on Better Operator Precedence scattered-thoughts.net/wr... · Posted by u/kelseyfrog

mayoff · 4 years ago

Swift works the way this article describes, except that instead of the rules being built in to the compiler, they are defined by the standard library, and you can define your own precedence levels and associativity for custom operators.

https://github.com/apple/swift/blob/3ea9e9e55281b9957d2b5486...

daniellehmann · 4 years ago

I don't know Swift, but does this mean there are expressions in Swift where the compiler returns an error, because the expression is ambiguous without additional parentheses?

(My understanding of the article is that it mainly argues for _partial_ precedence, not so much that precedence/associativity can be defined in the program - the latter is also the case in other languages, e.g., Haskell.)

daniellehmann commented on Facebook-owned sites were down facebook.com/... · Posted by u/nabeards

antocv · 4 years ago

Its alive!

drill @1.1.1.1 www.facebook.com ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 2172 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.facebook.com. IN A

;; ANSWER SECTION: www.facebook.com. 3401 IN CNAME star-mini.c10r.facebook.com. star-mini.c10r.facebook.com. 3403 IN A 31.13.72.36

daniellehmann · 4 years ago

See e.g. https://www.digwebinterface.com/?hostnames=facebook.com&ns=a... for responses from different nameservers.

daniellehmann commented on Everything Old Is New Again: Binary Security of WebAssembly [pdf] unibw.de/patch/papers/use... · Posted by u/xctime

canada_dry · 5 years ago

Great overview. Would it be correct to characterize the fwrite capability as one of the more concerning potential exploits (ie. esp. when combined with other browser vulnerabilities)?

daniellehmann · 5 years ago

Thanks.

You are referring to the example exploit in section 5.3, right? Please note that this example is for a standalone VM, not inside the browser (where JavaScript programs -- and by extension, WebAssembly modules -- do not have direct access to the filesystem).

Whether that exploit is more or less concerning than the browser and Node.js examples, I think is hard to answer in general without additional qualifications. If the standalone VM uses fine-grained capabilities (e.g., libpreopen) or is sandboxed, then changing the file that is being written to might be possible inside WebAssembly memory but access could be blocked by the VM.

daniellehmann commented on Everything Old Is New Again: Binary Security of WebAssembly [pdf] unibw.de/patch/papers/use... · Posted by u/xctime

cbsmith · 5 years ago

Alternate title: We Learned Nothing About Security From Applets

daniellehmann · 5 years ago

I don't think that's a fair assessment, and it is also not fair to the designers of WebAssembly. They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. This is what we call "host security" in the introduction of the paper. Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can.

However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)

daniellehmann commented on Everything Old Is New Again: Binary Security of WebAssembly [pdf] unibw.de/patch/papers/use... · Posted by u/xctime

titzer · 5 years ago

The decision to not (yet) have finer-grained protection for WebAssembly memory pages was in part motivated by the JS API surface in the web embedding. WebAssembly memories are exposed to JS as ArrayBuffers, and optimizing JITs can and do optimize ArrayBuffer access down to naked stores and loads. In addition to the optimized JIT code, ArrayBuffers are used throughout the webstack for moving data into and out of programs (read: Chrome's 6 million lines of code). The entire webstack is not really prepared for read-only ArrayBuffers causing signals underneath.

That said, we always knew a day would come where WebAssembly would get the ability to set more page protections. For non-web embeddings, this is easier, but as of yet, none of the engines I know of have either an API or are really prepared for the implications of this. I am still bullish on eventually getting that capability, though.

Thanks for your paper.

daniellehmann · 5 years ago

Thanks a lot for the additional background, and also for all the work on WebAssembly. It is a very cool language and having it available with linear memory now is much better than if it were still in the works due to figuring out page protections.

As you said, I just hope page protections can still be added later (somebody needs to specify it, embedders need to be able to implement them, toolchains need to pick it up, etc.).

Maybe memory vulnerabilities inside WebAssembly programs can also be mitigated in other ways that do not require such pervasive changes, e.g., by keeping modules small and compiling each "protection domain" (e.g., library) into its own module, or to have a separate memory. I am not sure about the performance cost of such an approach, though.

daniellehmann commented on Everything Old Is New Again: Binary Security of WebAssembly [pdf] unibw.de/patch/papers/use... · Posted by u/xctime

modeless · 5 years ago

It's easy to misunderstand this paper. This is not about breaking out of the wasm sandbox. You can't use these vulnerabilities to take over the browser, execute arbitrary code, install malware, etc. This is only about modifying memory inside the sandbox.

By modifying memory you could potentially cause the existing code in a wasm binary to do unexpected and potentially malicious things inside its sandbox. Which can be bad. But no more than that, unless you can chain it with other types of vulnerabilities. And using safe languages for your wasm code helps. The paper also points out that uses of wasm outside the browser, e.g. in node, may not be securely sandboxed.

I hope that wasm people are looking at adding mitigations for some of these attacks. Stack overflow in particular seems like something that can be protected against.

daniellehmann · 5 years ago

Good summary and clarification. Yes, we do not aim to break out of the (browser) sandbox, and yes the example exploits only use functions that are already imported into the vulnerable WebAssembly module.

However, I would draw a bit more attention to the consequences when memory vulnerabilities in a WebAssembly binary are exploited:

(1) Not every WebAssembly binary is running in a browser or in a sandboxed environment. The language is small, cool, and so more people are trying to use it outside of those "safe" environments. E.g., "serverless" cloud computing, smart contract systems (Ethereum 2.0, EOS.IO), Node.js, standalone VMs, and even Wasm Linux kernel modules. With different hosts and sandboxing models, memory vulnerabilities inside a WebAssembly binary can become dangerous.

(2) Even if an attacker can "only" call every function imported into the binary, it depends on those imported functions how powerful the attack can be. Currently, yes, most WebAssembly modules are relatively small and import little "dangerous" functionality from the host. I believe this will change, once people start using it, e.g, for frontend development -- then you have DOM access in WebAssembly, potentially causing XSS. Or access to network functions. Or when the binary is a multi-megabyte program, containing sensitive data inside its memory.

Sure, the warning is early, but I'd rather fix these issues before they become a common problem in the wild.

daniellehmann commented on Everything Old Is New Again: Binary Security of WebAssembly [pdf] unibw.de/patch/papers/use... · Posted by u/xctime

miohtama · 5 years ago

I do not understand the point of this paper. The correctness of the binary is the issue for a compiler, not for the run-time. It mainly discussed mitigations against legacy C code. E.g. new Rust code does not have these issues. Furthermore mitigating issues runtime has a performancy penalty and I do not want my code to be slower because some old C issues from back in the day.

daniellehmann · 5 years ago

Daniel here, one of the authors.

You are right, some of the issues highlighted in the paper could be solved by compilers targeting WebAssembly. One such mitigation that is (currently) missing are stack canaries. In contrast, stack canaries are typically employed by compilers when targeting native architectures. They also cost performance there (typically single digit percentages), but evidently compiler authors have decided that this cost is worth the added security benefit, since fixing "old C issues" in all legacy code in existence is not realistic.

Note however, that other security issues highlighted in the paper _are_ characteristics of the language, notably linear memory without page protection flags. One consequence of this design is that there is no way of having "truly constant" memory -- everything is always writable. I do think that this is surprising and certainly weaker than virtual memory in native programs, where you _cannot_ overwrite the value of string literals at runtime.