Hacker News new | past | comments | ask | show | jobs | submit login
WRT120N fprintf Stack Overflow (devttys0.com)
189 points by pedro84 on Feb 19, 2014 | hide | past | web | favorite | 42 comments



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:

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.


I clicked the link expecting not to understand what was happening.. but wow.. thats insane


same here - I thought it was gonna have like 10 bash shells open with some crazy buffer flow


That was the user authentication equivalent of the Jedi hand-waving mind trick.


While they've come a long way from implementing security on the client side, they still do not appear to take it very seriously: http://arstechnica.com/security/2014/02/dear-asus-router-use...


This one is pretty hilarious.


Wow. But bad guys don't read HTML, right? And they don't use wget or firebug, or the like, right?


Use OpenWRT people. Modern kernel. Good security. Can be configured with devops tools like Ansible (assuming you have the flash to load Python).

https://openwrt.org


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).


I have a (disabled) wrt120n and unfortunately, it doesn't support openwrt or dd-wrt :(


Note this is technically a stack buffer overflow, not a stack overflow.


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

- Read MISRA C


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..


Even a rookie would spot this mistake, but he would need to learn a lot before exploiting it. But with a nice target like this one... :)


I don't agree that this is a valuable target. AFAIK most consumer routers disable access to the web interface from outside the LAN range (by default).


And now your weakest device can CSRF remote access back on.

Most people don't take their router in to a repair shop when the get a virus on their computer.


Yes but you can break almost any routers wifi password in 24hrs.


But you have to be in range of the wifi to do it. This isn't something that's going to be a widespread problem.


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.


The answer is to stop using C. It doesn't even have to be in Haskell. Hell Lua stops this class of bugs.


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.


openwrt runs Lua, and runs on many of these boxes. It is pretty small and you can cut it down further - eLua runs happily on microcontrollers.


eLua runs on this board, STM32F4DISCOVERY http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252... and is quite easy to setup following instructions from http://www.fussylogic.co.uk/blog/?p=1222


Or you could sanitize the inputs a wee bit.

Just a thought. Seems like less a perturbation than rewriting a limited resource device for one feature.


> Or you could sanitize the inputs a wee bit.

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.


I still remember HN/reddit bashing Chinese crap router with crap firmware yesteryear :)


It seems that all router/home networking device firmware is universally shitty and full of holes.

Example: http://securityevaluators.com/knowledge/case_studies/routers...


With consumer gear it's a race to the bottom.

Until customers will demand more security than fancy features this problem will not be addressed.


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.


This article reminds me of a talk given at 29c3:

http://youtu.be/f3zUOZcewtA

Embedded devices are woefully insecure and no one seems to care!


"I respect myself. That's why I refuse to use sprintf"

hahah. Nice.


It's from [0], which was on HN not too long ago [1].

[0] http://natashenka.ca/posters/ [1] https://news.ycombinator.com/item?id=7156405


What editor is that?


It's a Disassembler - Ida Pro

https://www.hex-rays.com/products/ida/




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: