You'll have to forgive me for the awful presentation format and pacing, but here's a fun trick for bypassing the auth system on the Asus WL-700gE circa 2007:
how safe is it to install OpenWRT? What are the chances of me bricking my router if I have no clue what I'm doing?
My model is sort of listed in their supported hardware section (it's the Japanese version of the Buffalo WZR-600DPH2, though the "2" at the end is missing in their database).
This is why I only buy routers that are known to be compatible with open source firmwares like Tomato, DD-WRT, or OpenWRT. I have never trusted OEM firmware, not only for security but they tend to be really buggy.
I'm far from an expert security pentester but I know my basics... and I'm always amazed at how simple these exploits are. Guys, come on, it's 2014, if you're writing C and using strcat/strcpy/sprintf/fprintf/etcetc with non-sanitized input, you're pretty much asking for it.
Even a rookie would spot such mistake and exploit it, it's always among the first obstacles to bypass at local CTFs and it's the #1 exploit that people think about when they think about a "security vulnerability".
On top of that, if one really needs to use C, then:
- Enable all warnings as errors
- Sanitize all inputs via assertions, or similar
- Provide proper unit tests
- Have a static analyzer configured for the continuous build that breaks the build if issues are found
- Specially don't allow anything to go through the static analyzer that is labeled as undefined or compiler specific according to the ANSI/ISO C standard
Well, its not quite that easy for a rookie as you say. Just because you can trigger a buffer overflow bug does not mean you can exploit it. Most modern processors will allow disabling execution with an IP-on-Stack test. Thats assuming you can actually control the IP... , and assuming you can actually deliver the payload in the corrupted program state and not crash the program, etc etc..
In other news, it's 2014 and people still use non-bounds-checked string libraries in C to deal with unvalidated and unauthenticated inputs from a network.
If you're building these things it depends what your target market is. How much you want to pay for flash, RAM, packaging, etc. When flash space is a premium (I'm talking 2MB) it becomes a tradeoff between using a tiny C webserver and having a few extra functions or adding a Lua interpreter and dropping those tools. We're talking operating in a margin of a few hundred kilobytes.
Also, some of these firmwares are based on an existing code base, it's just cheaper to hack it than replace it.
If you sanitise inputs a wee bit, chances are you'll forget some. Or some endpoints. Or you'll sanitise based on ASCII but accept non-minimal UTF-8 encoding. Or non-ascii encodings altogether.
Making it extremely hard to impossible to implement the error class sounds like a better idea.
Not for a cost-constrained network appliance. I think you're overestimating how hard this is. Maybe I'm underestimating it - I've been doing things in a "safe"
manner since the 1980s in 'C'. It's second nature to me.
And I've never even been interested in UTF-8, much
less implemented anything that uses it.
I think the OP is a little too cute with "don't use sprintf()" - it and snprintf() can both be used completely safely.
Now, it may well be that the UI can be completely done in, say, eLua and the guts of the thing done in 'C'. I'd go for that if it made any sense to any body else on the team. As a practice, I avoid working on things that will be on the larger Internet.
Every time I see stuff like this (buffer of some convenient fixed length, no real attention paid to its length) I really wonder whether whoever wrote that code ever thought of how long a string could be (the entire address space of your process, basically), what the limits are, etc. If vsprintf() had the same 256-byte limit on its output buffer, there wouldn't be any overflow. If this fprintf() implementation was documented as to be used for output not exceeding 255 bytes, maybe who wrote the caller code would use "Location: %.243s\n\n" instead. Although a fully general fprintf() should not have any arbitrary limits like that, in a special-case embedded system like this it's not uncommon --- but if it has limits, they should be documented clearly.
I think it's not a matter of language or "safety" or "security" or anything else; it's a very, very, VERY simple matter of knowing the sizes and limits whenever you write code or design anything. Somehow I think all this... astounding ignorance stems from the misconception that memory is somehow an infinite resource, or the discouraging "if you need to know the limits, you're doing it wrong" type of thought. It is very important that you know the limits, so that you can work within them.
(Capitalising the words "Stack Overflow" is now a bit confusing, thanks to the site of the same name...)
For those following along at home remember that MIPS has a delay slot. That's why the add is listed after the jr even though the add is executed before the return.
For routers? What fancy features? They want a cheap way to create a wi-fi network that doesn't crash. Only a small fringe group of consumers have interest in exotic features in their wifi routers.
Are there ANY hardware manufactures that know how to write software? It seems like both firmware and hardware were an afterthought to almost any piece of computer hardware I have seen.
Man having worked on a few router firmware sources I'm surprised there's not an exploit for every router out there, except maybe for the OpenWRT ones.
There was one router that had a built in backdoor, lets say you hit the router on a hidden page /sysctrl.html, which gives you essentially a poor-man's console with an input to send any command as root and it writes the output into a textarea. I mean it's as simple as launching telnet and then you're on the router as root.
I had one like that close to a decade ago (cheap ZyXEL, /syscmd.asp). However, I treated it as a feature; I think it was my first Linux-based router. That, and I only found it by exploring the filesystem base on the ping prompt that (IIRC) was passed to the shell without escaping semicolons...
I _think_ that page was behind auth; either way, anybody who had gotten on my home router could just have stepped over and unplugged it, so it wasn't an issue in my case.
http://www.toaster-of-doom.com/~brandon/no_crawl/router/
Spoiler alert: it makes the WRT120N look like Fort Knox. These companies have come a long way over the years.