Did you hear the one about Cisco routers using 
strcpy insecurely for login authentication? Makes you go AAAAA-AAAAAAArrg *segfault* Cisco has patched three of its RV-series routers after Pen Test Partners (PTP) found them using hoary old C function strcpy insecurely in login authentication function. The programming blunder can be exploited to potentially hijack the devices. PTP looked at how the routers' web-based control panel handled login attempts by …
Null suggested latterday C authors might want to switch to strlcpy instead, "a nonstandard function which takes a third length argument, and always null terminates".
Or better yet, the strncpy_s function that is standard in C11.
If using a pre-C11 compiler then write your own (from scratch or by encapsulating any provided non-standard one) until you can upgrade your compiler.
strncpy isn't a good choice, not least because it doesn't null-terminate excessively-long strings.
I didn't say strncpy, I said strncpy_s. Passed the correct arguments, it guarantees a trailling NUL and provides simpler error checking in the event of an overflow. It also detects overlapping source & destination. Its behaviour is precisely defined by the standard.
strlcpy is not portable or defined in any C standard, although one might wish it was given its simpler signature. So its behaviour is not predictable when porting. *shrug* One could add tests of its behaviour to the unit test suite for every project I suppose.
But we're getting into nerdland here so I'll leave it at that.
Original bad designs in C biting back... how many different functions are they going to add trying to address them, before understanding that the lack of a string intrinsic type properly managed will solve most of those problems? Keep on thinking manipulating arbitrary buffers when there's really no need, and this vulnerabilities will keep on surfacing.
Strings could have been a lesser need in the mainframe era, but today too much became a string (even when not really needed, thanks to the web and its clueless protocols and developers), complicating their manipulations is just a big vulnerabilities source.
Sadly strncpy_s is not that standard other than for MS' own compiler. Using it paints you in to an MS-only corner or having to use some unusual gcc varient. Unfortunately the strlcpy() variant mentioned is also not a general standard, so again using it paints you in to the corner for coding.
As the article points out, there are already standard options for this, even decades ago there was strncpy() that copied with a length-limit, but that has the issue of not enforcing nul-termination if you use the full buffer length. I generally always set the last byte of the known-size array to zero afterwards just in case.
Tools like the synopsis "Coverity Scan Static Analysis" would pick that sort of thing up, and it is utterly inexcusable that a company of such size and price-tag is not checking code automatically.
of the source would have revealed an unsafe use of the function, known to be bad news for decades now.
Total Irresponsibility To Show Usual Prudence. I've used your approach myself along with a couple of other trivial tricks to totally prevent stack corruption - since long before the big issue was someone malicious trying to do it.
I mean, that should have been proactively searched for and fixed quite a long time ago....that's plain irresponsible, it wouldn't take a whole dev-day to do all their source that way....unless their system is really an example of utter borkage.
Either way, it's a sign you should vote with your wallet. No, of course.
Yeah. Jump from the Huawei Chinese intelligence taps frying pan to the NSA taps fire . . . Use of the word "trust" should be banned when discussing anything that involves communications devices produced by US companies unless preceded by the word "not." None have provided any evidence that they /*can*/ be trusted and all, at one time or another demonstrated that they cannot be. One might begin by following the breadcrumbs that show up when one Googles "Room 641A."
"PTP's Null suggested latterday C authors might want to switch to strlcpy instead, "a nonstandard function which takes a third length argument, and always null terminates""
That can work unless, like me, you're working on code that must be able to compile on a wide variety of operating systems and platforms. In those cases, nonstandard functions must be avoided, or you need to implement them yourself rather than using library functions (which is rather expensive in such circumstances).
The better solution is to hire competent programmers and rigorously enforce code reviews to catch this kind of nonsense.
Tried this, doesn't work.
Even the brightest engineers occasionally make mistakes, and unfortunately when you make a mistake anything can happen from a benign issue to accidentally launching the nukes.
The solution to this problem is fairly well understood, you design the language to make these sorts of bugs impossible. There is a slight memory overhead to achieve this, but performance wise the impact is fairly minimal because often the compiler can often optimize the bound checks away.
"Even the brightest engineers occasionally make mistakes"
Absolutely true. That's why we have a need for code reviews and comprehensive testing.
"The solution to this problem is fairly well understood, you design the language to make these sorts of bugs impossible."
That's not really a solution, big picture. It's just playing whack-a-mole. You can design languages to make certain sorts of mistakes impossible (often at a fairly high cost), but you can't design language to make all forms of serious mistakes impossible. So, although using "safer" languages can help, they are not comprehensive solutions. The real solution is to engage in proper engineering practices (one of which is to use the right tool for the job).
I think that you're a bit too dismissive about the importance of speed, but that likely depends on the sort of applications you're developing.
"it's fast but you have to be super careful"
I agree. But you have to be super careful in all the code you write anyway. Or you should be. Using a more protected function may be safer, but if you think that means you don't have to be as vigilant or cautious in your coding, then I think you're making a big mistake.
This post has been deleted by its author
It baffles me how so many developers, even ones writing security-sensitive code, will just turn off all security features and never bother to turn them back on. Like, sure, turn off the NX/XD bit and ASLR, etc during development to get proper debugging, but once the code is working without them, they should be turned back on and the code retested before release.
>>>"some form of embedded Linux" instead of Cisco OS<<<
Quite a lot of Cisco high end tat has also used some form of linux underneath for a while, the rock solid IOS of yesteryear (runtime in years) is just a happy memory. Now I know linux isn't the problem here, I can only assume Cisco have gone cheap with hiring replacement developers as the old crew retire.
The number of serious bugs we've been dealing with for the last few years is terrible, the craziest one caused the switch CPU to run at 100% constantly and you had a 1 in 10 chance of a stack not returning from a warm boot. (great news if you are in a different continent doing out of hours maintenance)
"The number of serious bugs we've been dealing with for the last few years is terrible..."
It's because the bean counters are running the show now.
Exactly the same problem at Cadbury.
I don't buy Crunchie any more, and until I was 50 I probably averaged one a day for my entire life.
Cadbury, where did it all go wrong. (Actually the Kraft buyout was the exact moment)
Creme eggs now are a shadow of their former self. Even the easter eggs, which used to be proper dairy milk, are now just a cocoa tasting lard hollow ovoid.
I've been looking over the pond where the bean counters are in charge of Ford. They had a few saloon cars on old platforms, and heavily marketed their SUVs. They've now axed the saloons because they can eke more profit from an SUV which doesn't need to meet stringent regulations as it is technically classed as a truck.
Certainly the Enterprise targeting Nexus devices run Linux natively, with a CLI shell, then a Linux container 'guestshell' as a bit of a sandbox.
Was recently involved with porting a devops tool away from using a native Linux agent, to instead communicating with the device remotely. Telcos generally don't like 3rd party executables on their gear.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
