Live data from Hacker News

‘Zero-click’ hacks are growing in popularity

bloombergquint.com

391–400 of 408 posts

Re: ‘Zero-click’ hacks are growing in popularity

#391

Earlier quoted context omitted.

I brought up ASAN because it's a real thing that already exists and gets run regularly. The broad details of how ASAN is implemented are best summarized in the original paper [1]. The practical short of it is that there are essentially no false negatives in anything remotely approaching real-world use. A malicious attacker could get around it, but any "better algorithm" would still run into the underlying issue that…

From the linked ASAN paper: "...at the relatively low cost of 73% slowdown and 3.4x increased memory usage..." That's too big a performance hit for production use - much bigger than you would get with the approach I outlined. I don't agree that any nontrivial C program is nonconformant, at least if you're talking about nonconformance due to invalid memory references. Referencing invalid memory locations is not the so…

With all due respect, why do you assume that your “thought about it 3 mins straight” idea would perform better than one that has been in the works for a long time now by people working on similar topics all of their lives?

Don’t get me wrong, I often fell into this as well, but I think programmers really should get a bit of an ego-check sometimes, because (not you) it often affect discussions in other fields as well where we don’t know jackshit about.

Re: ‘Zero-click’ hacks are growing in popularity

#392

Earlier quoted context omitted.

No, I would not blame the teams or their managers. You can't just blame a manager you've never met just because he's a manager, we're talking about the manager of Apple Music, they could very well be capable and well-minded, likely personally capable of coding. So let me give you another example in the same vein as C, where everybody uses a technology that is terrible, questioning it only at the outset, and then just…

You're being downvoted to oblivion, even though your general point (rephrased, C is an unforgiving language and safer languages are a Good Thing) is pretty mainstream. Here are my guesses why: 1. You start off by saying you can't just blame the team or their manager if you're dissatisfied with a product, then instead of explaining why the people who made a piece of software aren't responsible for its faults you go of…

> So, is C good or not? We're talking about memory safety, C provides literally none. Is this not objectively inferior? Now, I would argue that it's not, it's an engineering trade-off that one can make, trading safety for an abstract machine that's similar to the underlying metal, manual control over memory, etc.

One might make the argument that Oberon, with its System module, provides the same memory control abilities but few of the disabilities of C.

> so claiming C is only good for 60-line prototypes is just weird.

That seems like a misrepresentation of the claim above?

> Um, most computer languages are "about characters". There are some visual languages, but I don't think you're comparing C to Scratch here... You can misplace a parentheses with Lisp or make any number of errors that are syntactically correct yet semantically wrong and you'll have errors too, just like in C.

Well, not really. Lisp is actually about trees of objects. The evaluator doesn't even understand sequences of characters. That you can enter it as a sequence of characters is purely coincidental, but there have been structured syntactic tree editors (sadly they went down for being proprietary and expensive at the time).

Re: ‘Zero-click’ hacks are growing in popularity

#393
post #5

Zero click hacks have been around for all of computing. Nothing connected to the internet, connected to a network, has ever, ever been safe. All you can do is reduce attack surface, and most of all, monitor. Another comment blames Apple, and financial incentives. Sure, there may be some of that. But the reality is that safe code is impossible. Now, you may say "But...", yet think about this. For all of computing hist…

You're missing the point. Humans cannot write bug-free software[1]. Then if you're soft has security-related things to do (like credential management etc.) you cannot be sure there won't be a way to bypass it. But here we're talking almost exclusively about remote execution bugs coming from memory-safety issues , which are indeed preventable. Any managed language does the trick, and if they are not fast enough for yo…

> (And, before anyone mentions it, since this isn't some low-level/hardware related thing, you don't need to use unsafe Rust).

That only makes sense if all your code is in Rust, but I suspect this is not true for foreign libraries, even bulletproof ones. It was my understanding that to convince Rust of their safety, you need blocks of "unsafe" code...or not? For example, if I want to embed Chez Scheme into a Rust program, even safely, I apparently can't do that without "unsafe" code. And that's by no means exclusively a "low-level/hardware related thing".

Re: ‘Zero-click’ hacks are growing in popularity

#394
post #392

Earlier quoted context omitted.

You're being downvoted to oblivion, even though your general point (rephrased, C is an unforgiving language and safer languages are a Good Thing) is pretty mainstream. Here are my guesses why: 1. You start off by saying you can't just blame the team or their manager if you're dissatisfied with a product, then instead of explaining why the people who made a piece of software aren't responsible for its faults you go of…

> So, is C good or not? We're talking about memory safety, C provides literally none. Is this not objectively inferior? Now, I would argue that it's not, it's an engineering trade-off that one can make, trading safety for an abstract machine that's similar to the underlying metal, manual control over memory, etc. One might make the argument that Oberon, with its System module, provides the same memory control abiliti…

> [...] Oberon [...]

Sure, and that would be a good argument, there are several interesting languages out there that do various things better than C. I'm not intimately familiar with the Wirth languages, but I thought Oberon provided garbage collection?

> [...] misrepresentation [...]

Fine, they never claimed it was only good for that, but I still find it weird to claim that "it's fine, it's great for X" where X is a thing that the language is not particularly good at, while ignoring Y, the thing it's well known for.

> [...] trees of objects [...]

I just don't think that "about characters" or "about trees of objects" is an interesting way to differentiate between programming languages, and I think that this discussion is actually confusing between two different properties. First, is how the source code is represented and edited. It's almost always as a plain text file. Some languages have variants on the plain text file: SQL stored procedures are stored on the RDBMS, Smalltalk stores source code in a live environment image. There are other approaches, such as visual editing as-in Scratch, or Projectional Editing (https://martinfowler.com/bliki/ProjectionalEditing.html) as in... um... Cedalion? I don't actually know any well-known ones.

The other property is how the language internally represents its own code. Sure, Lisp has the neat property that its code is data that it can manipulate, but other languages represent their code as (abstract) syntax trees, too. Basically every compiler or interpreter for a 3rd generation language or above, i.e., anything higher-level than assembly language, parses source code the same way: tokenization then parsing into an abstract syntax tree using either manually-coded recursive descent, or a compiler generator (Bison, Yacc, Antlr, Parser combinators, etc.) So your point that the Lisp evaluator doesn't even understand sequences of characters is true for any compiler, they all operate on the AST.

I think that there's a point to be made somewhere in here that one language's syntax can be more error-prone than another's, but that wasn't the argument being made... Not that I understood, anyway.

Re: ‘Zero-click’ hacks are growing in popularity

#395

Earlier quoted context omitted.

You should not have faith in software. You should verify and isolate.

I very explicitly didn't say "software". You should be distrustful of software. If you can't trust the system you've created, you've used or created bad software and then failed to build necessary safeguards. The answer is not to restrict the user, it's to make more robust systems.

What do you mean by "system you've created"? I didn't create anything. I use third-party software (e.g. Firefox) on my third-party OS (e.g. Debian).

Qubes runs Debian in a VM and isolates it to defend the user from threats.

Re: ‘Zero-click’ hacks are growing in popularity

#396
post #47

Years ago we used to regularly have worms that’d infect millions of computers without any clicks at all. The truth is that “Zero-Click” hacks are becoming increasingly rare. But of course everything is new for journos unfamiliar with the field.

Yes, Chrome pretty much single-handedly changed that, timed well with Vista. For about a decade we got a reprieve because: 1. Memory safety mitigations became much more common (Vista) 2. Browsers adopted sandboxing (thanks IE/Chrome) 3. Unsandboxed browser-reachable software like Flash and Java was moved into a sandbox and behind "Click to Play" before eventually being removed entirely. 4. Auto-updates became the nor…

And now you never know when your useful browser extension is going to auto update into malware!

Re: ‘Zero-click’ hacks are growing in popularity

#397
post #392

Earlier quoted context omitted.

> So, is C good or not? We're talking about memory safety, C provides literally none. Is this not objectively inferior? Now, I would argue that it's not, it's an engineering trade-off that one can make, trading safety for an abstract machine that's similar to the underlying metal, manual control over memory, etc. One might make the argument that Oberon, with its System module, provides the same memory control abiliti…

> [...] Oberon [...] Sure, and that would be a good argument, there are several interesting languages out there that do various things better than C. I'm not intimately familiar with the Wirth languages, but I thought Oberon provided garbage collection? > [...] misrepresentation [...] Fine, they never claimed it was only good for that, but I still find it weird to claim that "it's fine, it's great for X" where X is a…

> So your point that the Lisp evaluator doesn't even understand sequences of characters is true for any compiler, they all operate on the AST.

Lisp does not really operate on an AST. It operates on nested token lists, without syntax representation. For example (postfix 1 2 +) can be legal in Lisp, because it does not (!) parse that code according to a syntax before handing it to the evaluator.

Lisp code consists of nested lists of data. Textual Lisp code uses a data format for these nested lists, which can be read and printed. A lot of Lisp code, though, is generated without being read/printed -> via macros.

Re: ‘Zero-click’ hacks are growing in popularity

#398
post #397

Earlier quoted context omitted.

> [...] Oberon [...] Sure, and that would be a good argument, there are several interesting languages out there that do various things better than C. I'm not intimately familiar with the Wirth languages, but I thought Oberon provided garbage collection? > [...] misrepresentation [...] Fine, they never claimed it was only good for that, but I still find it weird to claim that "it's fine, it's great for X" where X is a…

> So your point that the Lisp evaluator doesn't even understand sequences of characters is true for any compiler, they all operate on the AST. Lisp does not really operate on an AST. It operates on nested token lists, without syntax representation. For example (postfix 1 2 +) can be legal in Lisp, because it does not (!) parse that code according to a syntax before handing it to the evaluator. Lisp code consists of n…

You're arguing semantics, I think. I would simply say that Lisp's AST is S-expressions (those nested token lists), and that the parser is Lisp's read function. Then your example is just something that's allowed by Lisp's syntax, while something like ')postfix 1 2 +(' would be something that's not allowed by the syntax.

What you say about Lisp code being generated without being read or printed is of course true, and while Lisp takes that idea and runs with it, it's not exactly unique to Lisp either; Rust's macro can do the same thing, without S-expressions. In other languages you usually generate source code, for example Java has a lot of source code generators (e.g., JAXB's XJC that used to come with the JDK).

Re: ‘Zero-click’ hacks are growing in popularity

#399
post #397

Earlier quoted context omitted.

> So your point that the Lisp evaluator doesn't even understand sequences of characters is true for any compiler, they all operate on the AST. Lisp does not really operate on an AST. It operates on nested token lists, without syntax representation. For example (postfix 1 2 +) can be legal in Lisp, because it does not (!) parse that code according to a syntax before handing it to the evaluator. Lisp code consists of n…

You're arguing semantics, I think. I would simply say that Lisp's AST is S-expressions (those nested token lists), and that the parser is Lisp's read function. Then your example is just something that's allowed by Lisp's syntax, while something like ')postfix 1 2 +(' would be something that's not allowed by the syntax. What you say about Lisp code being generated without being read or printed is of course true, and w…

The parser for s-expressions is READ. S-Expressions are just a data syntax and know nothing about the Lisp programming language syntax. Lisp syntax is defined on top of s-expressions. The Lisp evaluator sees no parentheses and no text, It would not care if the input text contains )postfix 1 2+( . The reader can actually be programmed to accept that as input. The actual Lisp forms need to be syntax checked then by a compiler or interpreter.

There are lots of language with code generators. Lisp does this as core part of the language and can do it at runtime as part of the evaluation machinery.

Re: ‘Zero-click’ hacks are growing in popularity

#400

Earlier quoted context omitted.

Nobody said it would be easy, but it is already happening. https://medium.com/@tinocaer/how-microsoft-is-adopting-rust-... https://preettheman.medium.com/this-is-what-apple-uses-rust-...

Did you even read what you linked? I wouldn't say "already happening" more like first early steps. Operating systems have a massive attack surface, would take years to convert code from C\C++ to Rust and likely be more vulnerable initially(the old code base went through decades of scrutiny, hundreds of scanners\fuzzers etc)

[deleted]
Post reply on HN