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 ;).
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.
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.
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.
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 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.
We use your eyefi server at our local hackerspace (hackerspace.pl). I haven't really touched the card myself (the setup was done by a fellow hacker), but I'll probably take a look at it some day, if there is at least some vague promise of RCE hidden somewhere.
> After navigating the filesystem and downloading scripts, it is obvious, and not surprising, that this system is using busybox...
Does anyone know whether Transcend provides source code [0] upon request? The EULA in the user manual for the product [1] mentions that it might contain "GPL Components", but I could not find any additional details.
"Perl has a nice feature when opening a file with the open() library call, because it not only opens files, but runs programs if the file path is not a path, but a shell command ending in a pipe."
I thought only PHP did things like that :)
I hope this is disabled in mod_perl? Because if not I need to let someone know they need to audit their code.
PS. I get how useful this is, and it's well documented, but this functionality should be in the ancillary function (i.e. used when needed), not in the default one.
I believe it's enabled under mod_perl. If that someone was allowing user input to make it to an open, system, or back tick call unfiltered then this is just one thing to worry about. It's as bad or worse than taking unfiltered input and building an SQL query with it.
Moreover, this isn't a Perl issue. I can think of ways to do similarly I'll advised things with C#'s process.start or C/C++'s System command.
I don't know what they did, it's not my code, but they are not experienced and I suspect they don't know to watch out for this.
> Moreover, this isn't a Perl issue. I can think of ways to do similarly I'll advised things with C#'s process.start or C/C++'s System command.
Obviously every language has ways to cause this. It's just that open is the default command. This extra functionality should be in a openshell command or something, and the regular open not have it. (And yes I'm aware it's way too late to change it.)
This is cool. Unfortunate in some ways that it has an AR6003 wifi, since ath6kl (the OS driver for the AR6003) doesn't have monitor or promiscuous mode support yet which means no sniffing or injection.
Because if it did, it would be an interesting choice for pen testing. You could recase it, and it's small enough that properly installed and configured, it would be difficult to find. Processor is fast enough to get some cool tricks going.
Of course, it's possible some clever kernel hacker will get those working on the AR6003 at some point, which would open up this, as well as a bunch of devices, to some cool uses.
It's very cool to be able to write remotely on a SD Card when you have for example a Makerbot 3D Printer, or any device with a SD Card reader but without wifi / ethernet connection: never plug in / out the SD Card anymore !
or maybe it could be used as a ultra low energy bittorrent client: the cpu should be fair enough (many router/nas use 800mhz-1ghz ARM cpu and they offer bittorrent and other clients) and even though this device is low on memory (32MB RAM) it looks like transmission client can use only 10MB or RAM: http://pastehtml.com/view/5tx16jw.html so MAYBE it could work.
Contrived, sure, but you could use these exploits to upload all files added to the card somewhere, assuming it can find a wireless network to connect to. Maybe even just keep a hidden copy on the part of the FS invisible to the host system if there is enough free space.
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 ;).