This would depend on them being able to guess your router's internal interface IP.
If you're not using 192.168.0.1 / or other common defaults, you're less at risk.
A hacker has discovered a critical vulnerability in open-source firmware available for wireless routers made by Linksys and other manufacturers that allows attackers to remotely penetrate the device and take full control of it. The remote root vulnerability affects the most recent version of DD-WRT, a piece of firmware many …
If you're not using 192.168.0.1 / or other common defaults, you're less at risk.
c'mon guys, i thought openwrt was supposed to be mature.
o-pwn-wrt more like.
Looking up the default gateway isn't too difficult. All that changing the router's IP address would achieve is protecting it from some really dumb software that has the address hard coded into it.
couple of days ago the null pointe rproblem on all lunixes .. now this...
For criticla stuuf : use something that is in-house built and nobody outside has the source of. Make ik so that the thing is not a clear split between an os and an app with installable modules.
Write code that uses static adresses and cannot load something dynamically. And lastly : run from ROM , not copy the software to ram and execute from there. Use a CPU that has different code and data space. ( Harvard architecture machine ) Such an architecture prevents from executing anything that was thrown into ram. It simply is not possible. You can buffer overflow and try all kinds of tricks to your hearts content , you will never succeed in the system executing whatever you fee dit. it will dutyfully execute from ROM only.
That is one of the big security flaws in today's systems : they copy the OS and the runtime software to RAM and execute from there. If it's in ram it can be altered. If its in rom it cannot be altered. And if you use a serious cpu that has physically different address/databus for code and data then it is impossible. all you can change is the data, you can never change the code. and it will not execute anything in the data address space.
hard day at the office?
This has nothing to do with OpenWRT. DD-WRT is a different project with a less than stellar reputation last I heard. Haven't really been paying attention lately because I switched to the (much better IMHO) Tomato firmware a while back.
Please explain to me how that could be determined by a web browser when utilising CSRF?
… that this is a system()-level exploit.
but am less than impressed with the obsfucation of the source, there is no way you can just check it out and build it, unlike just about every other open source project.
It seems like the cvs/svn code is all there, but has been intentionally broken. Probably as a means of stopping users customising it and 'encouraging' them to pay for mods or buy the 'full' version from their online shop. It does however mean it complies with the letter of the open source licence.
Also, the current version is lagging quite a lot, last service pack release had major bugs in it.
I use about 70 routers with it, and it has made available really cheap hardware to do the same job as much more expensive ones, but I'm going to be moving away from it asap, this is just nudging me along.
If you stop by the forum, beware of the rabid fanbois.....
Thanks for the tipoff about Tomato - looks interesting, although methinks it shall be a project for the morrow as it's gone 4:30am.....again.....
Cheers to you sir!
Good job all my router does is route (actually, not even that, it only passes packets from the telco). The management interface isn't accessible, even by me, as everything is firewalled away on a different box.
Of course the firewall then has the possibility of being vulnerable, but historically it's pretty solid..
@open sauce = fail ... !? ... Ok... Thanks.
This vulnerability is beggars belief! I am infinitely glad I switched to Tomato a long time ago.
I really must get around to setting up my PC Engines WRAP OpenBSD router!
This exploit, as pointed out already, is a DD-WRT problem and is probably best solved by flashing your router with OpenWRT.
In fact I'd recommend anybody with a wireless router to flash it with openWRT, you get sooooo much control over what you can do. Head over to http://x-wrt.org/ for the webIF version.
The webIF is the most powerful webIF I've ever seen on a router.
Sure if you use ROM or hard wiring for your code then it can't be changed. Fine if it was secure in the first place, but proprietary "security through obscurity" code doesn't have a good reputation here either. Flash upgradable systems are all vulnerable unless there is a hardware reset required to enable it so this can't be done without physical access to the device. But that also makes the router cost a few pennies more and prevents full remote administration.
Besides which, I doubt the firmware in question was designed with security against someone or software with LAN access in mind. Seems useful to someone parked outside who has just cracked your WEP keys and wants to take over your router and run something on it more permanently though.
Just last night I was playing with a WRT54GL and flashing DD-WRT onto it with a view to swapping out the more power-hungry Linux machine I use as a border router to a couple of internet interfaces. I guess I'll wait a while before deploying it then...
Anyone seen the code in question? Is it something creatively forgetful or a nice juicy sprintf/strcpy without a bounds check? This reminds me of a time several years ago when I was reading through the source of a certain "open source"(ish) firewall package, lot's of evidence of enthusiasm (Or in that case enthu$ia$m) without any real talent.
This reminds me of a university joke from about ten years ago, flap your hands around and say in a goofy voice. "Wow! I Can Type! I'm going to write GPL Software"
Learn to type, I'm dyslexic and even I can manage better than that! P.S. Goodluck implementing a home router on an Arizona Microchip PIC.
REG READER FAIL
At least read the article and have a clue about what your talking about before you start spouting off about how other people suck.
DD-wrt has a fancier web interface, but OpenWRT has always been much more solid and professional.
A while ago I realised what I had against Open Source. It's not actually that it is free stuff, it is the fact that so many people seem to use open source as a way to cut costs. Your point was that critical stuff should be written in house, while Open Source does mean sharing not only the burden of testing but also the risk of points of failure it should also mean that you have two hundred times more testers.
Just because code was written in house, it does not make it necessarily better code. All code should be tested and certainly all code written externally to the company should be tested doubly. If the manufacturers of these two hundred products had tested then perhaps this bug would have come to light before getting into production. Clearly it seems that the assumption was that someone else will have tested so why bother.
I'm gobsmacked by your comment Vincent. You point out 2 flaws Linux has had and declare open source is fail? You're a tool - why don't you ask Microsoft about how security through obscurity is working for them
And @Lost in a maze of twisty messages, all alike - Good luck trying to bind to port 80 as a non privileged user
Shut up until:
a) You can use a spell checker (and it's source not sauce, it not bloody ketchup)
b) You know what the f**k you are talking about.
If you build it into ROM and and a security flaw if found, prey tell, how do you fix it? Flash it? In that case you just nulled the point of ROM.
Harvard architectures *have* to have a back door to let you load data into program space. Typically you need to be privileged to actually use them. For all practical purposes, a CPU with a no-execute capability in its page permissions can emulate a Harvard architecture.
Of course, running daemons as root circumvents any amount of good design.
All very well, but running from ROM is much slower than running from RAM and changing the architecture of all the hardware out there would make your router very expensive indeed.
Keeping the software in house would be sensible from a security POV, but too expensive again, and would have more bugs in it that the OSS variant - and of course, why re-invent the wheel?
BTW, I hardly think 2 faults in disparate Open Source software is a major failing. At least these two faults are known and being fixed, unlike closed source software where you never even hear of the faults (and there are many many faults).
Just finished your first year Computer Science classes, did you?
Gott-darn it. I was getting peeved with it already- wireless randomly switches off every day or two- whole interface is slow and flaky. I'm going back to Tomato. I really can't fault it's slick stability.
OpenWRT has always been better than Tomato or DD-WRT. It doesn't have this flaw from what I can see.
I've been using DD-WRT for a couple of months and I've been really impressed but I was thinking of trying another firmware because my virgin media 10Mb connection rarely delivers over 2Mb when I go through my router. This news and discussion will motivate me to install Tomato as soon as I get home from work tonight!
>" And @Lost in a maze of twisty messages, all alike - Good luck trying to bind to port 80 as a non privileged user "
So both you AND the DD-WRT team have never heard of the concept of privilege separation or dropping uid0 after you've bound your listening socket?
OMG! This exploit is working like a charm.
please stop feeding the trolls - that is all
I can't help wonder; how many more manufacturers may have adopted the http engine?
Guys, don't feed the troll.
>Keeping the software in house would be sensible from a security POV
Obfuscation != Security
I know, back when I was young, I hacked a lot of software packages to use the unsupported graphics on my Olivetti / ATT / Xerox PC Compatible. Never did see a source listing.
I think you mean "Just FAILED your first year computer science classes";-)
Obviously the guy's a troll, but it's got me thinking. Apart from PIC, I can't think of any other part which has separate data/code busses on the memory side of the cache system. There are some ASSPs such as Cirrus's PDA-in-an-SoC that have separate busses to deal with Dynamic and Static memory technologies, but they're still in the same address space. Lots of bare CPU cores export an opcode fetch signal (Which can be used to enforce non-executable memory.) It's the give away of true troll or jerk. Demanding the use of parts that don't even exist!
And for fuck's sake trolls, yes it's amusing to watch you murder the subject matter, but PLEASE don't chew up the language to do it.
Here is a clarification of my point : ( yeah my typing is bad sometimes , and no i'm not a troll. i am simply baffled by bad hardware/software engineering these days. Nasa flew to the moon and back, 40 years ago with 16 kilowords of memory space and a multitasking system running on a computer made only with dual nor gates ( fairchild 914's) ). Today we need a 5 megabyte kernel just to get to the point where we can start running an application... An old adagy says that any extra line of code adds a potential extra problem.
A mayor flaw with running critical code from ram is that: any memory leak ( whether a software bug , a shortcoming or an unintended side effect ) or a buffer overflow ( whether maliciously caused or not) can alter the intended loop of the program.
Running from ROM solves these problems. Code is unalterable. Additional traps in the rom image can force a reset.
Here is how i build critical systems the last 10 years: ( ARM based)
A real ROM ( not E2 or Flash but mask rom ) holds a bootloader. ( the bootloader is very small . about 76 words ... ) All this bootloader does, is initialise the SDRAM controller and then copy the executable code from FLASH to SDRAM. When this is done the bootloader sets a hardware flag. This flag can only be cleared by a power cycle or a hard reset ( somebody has to physically waddle over there and press the button ). The flag is used by the sdram controller to 'seal' a block of memory ( a simple hardware address comparator checks for a range of addresses and blocks write operations from the cpu side ). This whole mechanism resides in hardware. The SDRAM controller can still perform the refresh cycle, only the CPU can not write there. That is blocked by hardware.
At compile time i inject dummy code between subroutines and in unused space. All this dummy code contains is a JMP <bootvector>. If the code runs away , or is forced in limbo by the whole system will autoreset ( the bootloader gets re-invoked ) For debugging purposes the jump leaves a marker behind that tells me from which address it has jumped. The bootloader sends this to the serial debug port.
You can try all you want, the CPU will never execute anything from data space. Only if you succeed in overwriting the flash can this be done. The flash mechanism is also protected. Once the bootloader has ran the write access to flash is disabled ( same settable-only flag mechanism ). Only the bootloader has the flash mechanism. In order to flash firmware you need physical access to the system , hold the reset button 3 seconds and then it enters flashload mode. Flashload runs from the top of the flash memory. You can not jump there once the system is running ( The hardware flag has cut off access remember ).
All that is required is a couple of flipflops. The flipflop clk and data tied to ground. The CLR pin goes to the physical reset button , the SET pin goes to an address decoder. If address matches and a 1 is on d0 then set the flipflop. The whole thing is 2 lines in verilog code. On silicon you don't even see it..
Of course it is no excuse to write bad code, but a few simple hardware blocks can prevent unintended data execution, runtime code corruption and intrusion. Even if you find a way to execute data (you'll need physical access to the box and probe it as in solder wires to it) , this can not alter the cpu code. If you land in limbo : automatic reboot from a clean copy. simple as that.
In one of my systems i have extended this hardware block. When the bootloader finished copying flash to sdram it stores the memory pointer in a 'topmem register' and seals it by setting the flag. A hardware block monitors the address bus. If an instruction fetch happens from any address above this 'topmem' value :hardware reset , invoke bootloader : start from clean code. game over. So even if all else fails the bus cycle betrays you and forces a hardware reset.
The only point where the system is 'vulnerable' is prior to sealing the memory spaces. But that is when the bootloader runs from mask rom in the asic. So you can not corrupt this block. Prior to exiting the bootloader the sealing bits are turned on and memory is locked down. There is no speed penalty because code sits in sdram ( albeit a portion that has write access blocked by hardware )
Try all you want , you will only fail.
It baffles me that almost nobody takes care to put such simple mechanisms in place. It does not bother the programmers (actually it helps in debugging. You'll very quickly discover if you have a problem since the box will reboot immediately. The jumpvector gives you an indication from where the problem originated. You do need to take care about how you do the layout of your code, and you need to inject the dummy jump instructions. But that is a matter of code discipline. You can easily script such things.
And there is again another 'modern problem' most code these days is simply compiled and slapped on the box. The programmers do not understand the cpu, the hardware or care about memory layout. They are used to high level languages and 'leave it to the compiler'.. most of them don't even know how compilers behave.
One of the dangers of open source is the false sense of confidence and security.
The excuse is that it's been overlooked by so many people , so it must be bug free..
The last couple of days have proven that wrong , once more... Open source is good , because you can LEARN how things work. But blatantly dropping a chunk of code in a system is plain stupid. It would be like putting a floppy with unknown contents in the drive and booting from it... in the 80's and early 90's that was a sure way to get nasties on your machine.
Anywhere a URI is allowed is a likely way to reflect the exploit to the router on the LAN.
Good ways to do this are with programs designed to protect you by validating mail headers or contents, or by applications like MMS. There are lots of these, rarely noticed by end users, and hard to find and fix properly.
These types of attacks on routers are very common, and they are not limited to routers.
My previous post about non-browser, non-scripting ways to deliver the URI attack needs some additional warnings. This type vulnerability is found everywhere, open or closed sources, all types of devices, software environments and applications, even when aggressive security practices are used.Obviously, using non-default configurations, disabling uneeded features and applications, etc. helps defend against this and most other types of attacks; but few organizations are willing or able to do enough to truly protect themselves from serious attacks.
As long as a single user is allowed to browse, email, open complex file formats (e.g. SWF and other video, PDF, HTML, XML, various MS Office types (DOC,XLS) or any Net-facing system provides services (Web,Email), your system will still be at risk.
The httpd interfaces of routers are a common attack vector, with many exploits publicly known, usually involving vulnerabilities that also affect others systems (e.g. apache). For example, processing a POST request absent a valid session and context -- thus alowing changes to security settings to allow WAN access with a new user/password used later by the hacker to gain access remotely to make further changes.
BTW The way many security bulletins are written gives most users a false sense of security. They use unalarming statements about getting the "user" to visit/access an infected web site, the user dismisses because they only visit sites they know and are using various tools for protection, unaware of all the ways URIs are used without user actions.
I inherited an old wrt54g with only 2 meg of flash and dd-wrt is the only thing that will run on it (micro). I can't believe none of the others even try to offer a cut down version. It also sucks that friggin linksys was stupid enough once upon a time to actively fight against their users being able to flash their routers with open source (why router had so little flash and crappy ass wind river os in first place). Linksys realized open sales and now actively advertises their routers are flashable but not on their older models. It is nice to have router setup just for gaming (haha misses and kids have to connect to another router with qos lower) but may have to rethink this strategy.
So Vincent, your comprehensive guide to sucking eggs, was well typed and at complete odds with your original post about running entirely from ROM rather than copying to RAM. There's also a notable lack of demands for end-to-end harvard architecture.
How much did it cost to get the guy who passed his exams to write it.;-)
BTW, Your gleaming architecture is still vulnerable to a few choice exploits, particularly since your earlier post suggested using static addresses all the way through. True you might have stopped flash being written, but since the typical home user reboots their router at most once a week, (When they use that mains socket for their vacuum cleaner.) a rooted router will stay tainted for days.
Wow - I couldn't believe this, so I had to ssh into my home box and try it for myself. This is beyond pathetic. How can you fuck up security so entirely badly? Patching doesn't seem like enough... I'm not sure how I can ever trust this project anymore.
Biting the hand that feeds IT © 1998–2017