Hacker News Reader

Comment by q3k | Hacker News Reader

My experience with embedded systems allows me to be fairly certain that this bugfest is due to an electronics engineer writing the software for the card. Way too often small R&D teams, especially working on new products, have EE people being assigned to part-time-embedded-programmer roles.

This is especially scary as some of these teams work on internet-facing pieces of hardware - home routers/gateways, etc. One cool weekend project to have is trying to get hold of an image of the firmware of your home router, run binwalk on it, try to extract the filesystem, and count the number of remote exploits you can spot in the CGI perl scripts (like they are, in 99% of the cases) found there. Yet another reason to run OpenWRT ;).

View on HN

As someone who's written software for all his life, I'll posit that most "software engineers" write code like this. People don't test corner cases; they just shit out code, check that it works in the browser, and ship it. That's why the regexes like /.PNG/ are in there: they work, but they don't prevent the security problems they intend to prevent. If the engineer writing the code had written unit tests that checked various filenames, he would have discovered the bug immediately. If there were code reviews by someone who knew even the tiniest bit of Perl, the `$user_controlled_command > file` bug would be gone. If the programmer had run Perl with taint mode enabled, he would have discovered this bug instantly.

I think it's a mental thing: most people writing code never think "how could this go wrong", since they assume that they don't make mistakes. If you don't have a healthy fear of the code you write, you're not going to test the corner cases or not write complex features.

Ultimately, I'm not complaining, because buggy software is great in the context of devices that try to prevent you from doing something with your own property. I especially encourage people to write their system-level software in C and use lots of strcpy calls. It ensures that I can root my phone even though the carrier doesn't want me to.

Another explanation is that there is no benefit to the manufacturer in writing tighter code. Tighter code means more time spent on testing and review, but probably wouldn't increase sales. From a bottom line point of view, the mantra is get it working and ship it.

Yep. Whenever you work in an industry that involves churning out software as quickly as possible, it's easy to appreciate that commercial pressures are often too great to test properly. Whereas with start-ups (for example), they're usually well funded and have a strong focus on building great software.

Reminds me of claims of deliberate backdoors. Of course, these can often be used for bad things too.

How can I as a developer be sure my unit tests are complete? How can we develop or improve that ability to think "what could go wrong?"

I don't think they developers of Android, iOS, or the PS3 (and many others) were using insecure coding practices. They still got rooted over and over again.

I don't think it's that they assume they don't make mistakes, but simply that they literally can't do any better. For some programmers, making something work at all is a mighty struggle, and once it does work, that's the best the can do.

We were all there once. It's a stage you hit when learning to program. Some of us passed through it, while others simply remain there forever.

There's an old saying I don't hear much these days: never give a software engineer a soldering iron and never give a hardware engineer a compiler.

I can attest to the low quality of router firmware, go grab the source from Billion or Netgear and have a look.

Homework question: What's running on your blu-ray player?

Java. Oh, don't worry, that's like totally secure.

[tries to keep straight face, fails utterly]

I really should start blogging - one of my many unfinished projects is a teardown and reverse engineering effort of a Philips BD player. Java isn't even the half of it.

I really do hope you consider writing that blog post. Everyone here, and on several other sites, would love to read the trials and tribulations of hacking something like a BD player. :) Even if its just a quick run down with some pictures and a little story, it would be worth it.

I'd really appreciate some early feedback on the stuff I'm writing, but you don't have any contact details in your profile - send me an email if you want a preview.

Please, do so. It would be interesting to read.

Please do!

Reply on news.ycombinator.com