5 ms·
Scary. I saw a tweet the other day from a job seeker who had been sent a repo of seemingly trustworthy code. The sender claimed to be working with a team that w
by 27theo 2y ago
Scary. I saw a tweet the other day from a job seeker who had been sent a repo of seemingly trustworthy code. The sender claimed to be working with a team that was hiring, or something along those lines. Of course, one file deeply nested within the folds of the project contained a block of obfuscated JavaScript designed to grab as much data from the job seeker as possible and transmit it elsewhere. Had the job seeker run the project without reading through it first, they would have been in hot water.
You can imagine some variant of this attack including a carefully designed Emacs Lisp payload, which the unsuspecting and desperate-for-a-job victim might open in Emacs. Surprising that the Emacs maintainers didn't fix it as quickly as you'd hope.
- medo-bear 2y agoEmacs doesn't market itself as a sandboxed tool. It is purpose built to give users unrivaled powers. There are obvious consequnces to this. What is more scary is running untrusted js in a browser that has been marketed as sanboxed, but you probably do this all day every day
- __MatrixMan__ 2y agoAgreed. Also, I expect that malicious elisp is relatively rare, while malicious js is probably about half of it.
- medo-bear 2y agoWhile I'm trying to sober up people who are panicking I don't mean to downplay the dangers. The op article is quite informative and should be read by all emacs users. While malicious el code is probably rare, the value gained by compromising an emacs user (programmers academics researchers etc) compared to compromising a random js user (everyone) is probably way greater. Also very few people look at emacs security
- deleted 2y ago[deleted]
- emporas 2y agoCould starting $ emacs --daemon, and connecting to another machine using the client act as a kind of sandboxing or it has no benefit whatsoever? Maybe that could be used as a starting point to implement a security strategy for some not totally trusted packages. It could complicate things, but hopefully not too much.
- medo-bear 2y agoIf you are concerned about security you should not be running arbitrary programs. For example if you have a lots crypto assets, you shouldnt keep your wallet details on the same computer you are running programs you don't trust. However, practicality often forces you to adopt a more yolo approach toward security. What people often dont realise is that emacs is almost an operating system, and installing emacs packages is kinda like insralling .bat or .exe files. To me personally emacs is the single best piece of software ever produced, by a long shot, but it is a good idea to be aware of its powers. Emacs can infact be great for security. Its code and language are very nice and well documented and if you care to understand the code you are running and you are THAT concerned about security it can be an excellent aid toward peace of mind.
- emporas 2y agoYeah, but does that mean, (supposing they are different machines), a package is installed on both computers? On the client and the server? It sounds redundant, and pretty strange if and that's indeed what happens. I will read eventually the docs and find out myself, but it's gonna take 2-3 hours to dig out documents. > if you care to understand the code you are running and you are THAT concerned about security it can be an excellent aid toward peace of mind. Elisp can be more difficult to review that Rust. It is much more difficult to hide malicious pieces of code, inside a Rust program that in Elisp. Elisp is pretty powerful as many lisps are, but you can write Emacs modules in Rust. See ubolonton's project on github. I tested it at some point and it works. >if you have a lots crypto assets If i had crypto assets, (which i don't), then the correct way to organize money units, tokenized pieces of housing, tokenized pieces of cars, a thousandth of a car for example, is to use an identity which can create children identities, and each child identity can be revoked on demand by the root identity or the parent identity. Then you only really have to keep secure the root identity, everything else is revocable.