D-Link patch doesn’t address all bugs listed in their own security advisory

I inherited an office with a D-Link router being used that kept misbehaving. I tried upgrading the firmware as a last resort, since DDWRT and the others don&#x27;t work on it.<p>Digging around I found a thread where customers were wondering what happened to bridge mode and why it had been removed. An obdurate admin informs everyone that D-Link decided it wasn&#x27;t needed as a feature, so they removed it. The admin is very coarse and ends up locking the thread.<p>It seems ridiculous that, for a hardware product, a company would decide to remove features in a firmware upgrade. There is a work around, but even if it is a legitimate thing to do, it seems like a terrible product and engineering culture to be this condescending to customers.<p>Relevant thread: <a href="http:&#x2F;&#x2F;forums.dlink.com&#x2F;index.php?topic=4542.0" rel="nofollow">http:&#x2F;&#x2F;forums.dlink.com&#x2F;index.php?topic=4542.0</a><p>End of story: The router ended up going in the trash after other issues, along with two different D-Link models.<p>It&#x27;s not the best idea to use consumer grade gear in an office, but then I replaced it (as a temporary fix) with an even older Linksys WRT54GL flashed with DDWRT with no problems.

I was in a dev team for a network security appliance. It is really sad they way they treat vulnerabilities and security advisories. There were very few people who know what the actual vulnerability was.The vulnerability would be listed as one of the last items in a release checklist. Gets assigned to a guy who has no clue whatsoever. The guy fixing the issue would google a patch. apply it. has no way of testing it comprehensively. He will run a basic test case. He will make up a report with a lot of security jargon for the managers and advisory team. And the next release would list the vulnerability as fixed.

I&#x27;ve just accepted that residential routers are full of assorted orifices (security holes, backdoors &amp; holes in functionality).<p>Then again I&#x27;m not hiding anything dubious - if I was I&#x27;d install a firewall box asap. (And yes I know the &quot;nothing to hide&quot; slippery slope etc argument)

Things like this make me so happy to have things like DDWRT, OpenWRT, et al.

this guy clearly has a passion for security.<p>d-link could do well by firing whatever uncaring 9-to-5 programmers they have and hiring him.<p>part of the problem is that people with this kind of passion and skill are few and far between... is very rare that good people want to work for a company like d-link on something like drivers or router software.

It&#x27;s better to stick with OpenWRT or DD-WRT.

Mirror for Database Error&#x27;d: <a href="https:&#x2F;&#x2F;archive.today&#x2F;D33zV" rel="nofollow">https:&#x2F;&#x2F;archive.today&#x2F;D33zV</a>

I guess this is a reminder that writing secure C is actually really, really hard.

I can&#x27;t believe how laughably bad router security still is. It&#x27;s fascinating how these exploits came to light. Where do you even start to map to the related system calls?

pfsense on a thin client = 40$ OpenWRT on a home router as AP = 30$ Not getting pwned = priceless

Interesting. The D-Link security advisory (<a href="http:&#x2F;&#x2F;securityadvisories.dlink.com&#x2F;security&#x2F;publication.aspx?name=SAP10054" rel="nofollow">http:&#x2F;&#x2F;securityadvisories.dlink.com&#x2F;security&#x2F;publication.asp...</a>) states that the issue was only partially resolved. What was changed (aside from adding an additional buffer overflow) in the patch that attempted to alleviate these issues?

Factory firmware on SOHO routers is notoriously terrible. You&#x27;d think that this would be a good place for a startup to disrupt. The hardware is basically off-the-shelf components. It would be an easy sell to experts, but maybe harder to get traction with most people.

I wonder which vendors have the best firmware.

Cheap SOHO routers: Sadly, you get what you pay for.