4 ms·

Are all of these *coins written in C? If you had a language not so easily obfuscated you could at least more readily find crap like this.

mschuster91 11y ago
Writing it in Java or whatever other language doesn't help. All programming languages can be obfuscated as fuck if you want it. Java and other OO languages actually encourage the trend to wrap everything in dozens wrappers, singletons, factories and other stuff, where malicious code can be spread over.
- deleted 11y ago
  [deleted]
- klibertp 11y ago
  > Java and other OO languages actually encourage the trend Java, yes. Other OO - not so much. Java is getting better now, but, for a long time, it was simply a weak language, with primitive type system and lots of necessary boilerplates. If you look at other implementations of OO, you'll see that the trend of "wrapping everything in dozens of wrappers and other stuff" is definitely not universal among them. Dynamic, reflective languages like Ruby and Python tend to have shallow class hierarchies and few wrappers; especially in Python, heavy use of inheritance and creation of classes for every little bit of data is considered un-pythonic. Then you have Smalltalk, which allows arbitrary code transformations on runtime, which further decreases boilerplate and makes a language more expressive. There's also Dylan and, of course, Common Lisp with CLOS. I'm working with StumpWM lately, a window manager written in Common Lisp - it does use classes and multi-methods, but very sparingly. WM is a piece of software, which is almost GUI only, and so in Java, you'd get a monstrous framework with myriads of classes and relations between these. In CL you don't need that at all - standard defuns and built-in data structures are enough for most things. Anyway, Object Oriented Programming comes in various sizes and shapes, and it's unfair to see bad Java code as "representative OO" code. JavaScript is OO, Smalltalk is OO, OCaml is OO(/FP), and Julia is OO. Take a moment (more like a couple of years, but...) to look at them and try to compare the languages' object models and the common practice of writing code. You'll see something amazing, more than once, I promise.
vidarh 11y ago
The problem is that the moment you think that code review will stop an adversary (and you should treat all the coin developers as adversaries as a matter of course here), odds are good you've lost, no matter what the language is. You should still review, but couple that with sandboxing the code in VMs (and as much as I love Docker etc.: that's insufficient), and make sure that you fully firewall that VM and the entire machine the VM is on off from everything else in your system. And crucially, that means ensuring that outbound access is also firewalled and filtered. In this case, the coins use of IRC (for discovery or something?) ought to have been a red flag and made them ask for a precise spec of what IRC traffic should be expected and ensure they were proxying and filtering and logging all the IRC traffic. This wouldn't stop the creator from embedding more convoluted command channels in something that looks like the normal message exchange with peers, but this was just way too easy. There'd still be plenty of scope for malicious code. E.g. the daemon could still have stolen all LuckyCoins deposited, for example, without requiring any suspicious communication, but at least with proper sandboxing and firewalling it'd be (if done right) isolated to that specific coin.

mschuster91 11y ago

Writing it in Java or whatever other language doesn't help. All programming languages can be obfuscated as fuck if you want it. Java and other OO languages actually encourage the trend to wrap everything in dozens wrappers, singletons, factories and other stuff, where malicious code can be spread over.

deleted 11y ago
[deleted]
klibertp 11y ago
> Java and other OO languages actually encourage the trend Java, yes. Other OO - not so much. Java is getting better now, but, for a long time, it was simply a weak language, with primitive type system and lots of necessary boilerplates. If you look at other implementations of OO, you'll see that the trend of "wrapping everything in dozens of wrappers and other stuff" is definitely not universal among them. Dynamic, reflective languages like Ruby and Python tend to have shallow class hierarchies and few wrappers; especially in Python, heavy use of inheritance and creation of classes for every little bit of data is considered un-pythonic. Then you have Smalltalk, which allows arbitrary code transformations on runtime, which further decreases boilerplate and makes a language more expressive. There's also Dylan and, of course, Common Lisp with CLOS. I'm working with StumpWM lately, a window manager written in Common Lisp - it does use classes and multi-methods, but very sparingly. WM is a piece of software, which is almost GUI only, and so in Java, you'd get a monstrous framework with myriads of classes and relations between these. In CL you don't need that at all - standard defuns and built-in data structures are enough for most things. Anyway, Object Oriented Programming comes in various sizes and shapes, and it's unfair to see bad Java code as "representative OO" code. JavaScript is OO, Smalltalk is OO, OCaml is OO(/FP), and Julia is OO. Take a moment (more like a couple of years, but...) to look at them and try to compare the languages' object models and the common practice of writing code. You'll see something amazing, more than once, I promise.

vidarh 11y ago

The problem is that the moment you think that code review will stop an adversary (and you should treat all the coin developers as adversaries as a matter of course here), odds are good you've lost, no matter what the language is. You should still review, but couple that with sandboxing the code in VMs (and as much as I love Docker etc.: that's insufficient), and make sure that you fully firewall that VM and the entire machine the VM is on off from everything else in your system. And crucially, that means ensuring that outbound access is also firewalled and filtered. In this case, the coins use of IRC (for discovery or something?) ought to have been a red flag and made them ask for a precise spec of what IRC traffic should be expected and ensure they were proxying and filtering and logging all the IRC traffic. This wouldn't stop the creator from embedding more convoluted command channels in something that looks like the normal message exchange with peers, but this was just way too easy. There'd still be plenty of scope for malicious code. E.g. the daemon could still have stolen all LuckyCoins deposited, for example, without requiring any suspicious communication, but at least with proper sandboxing and firewalling it'd be (if done right) isolated to that specific coin.