Another reason not to run DD-WRT

Embarrassing is an understatement.

• Open-source firmware vuln exposes wireless routers
• Open-source firmware flaw exposes wireless routers – DD-WRT
• http://www.securityfocus.com/bid/35742/info

Tomato users are not affected. No idea regarding HyperWRT or Thibor.

Sebastian Gottschall’s statement, “consider that this exploit was released without any report to us”, is a miserable attempt at taking responsibility for the mistake. I have personally reviewed the DD-WRT source many times while working with WRT* routers — and like Busybox, it’s all duct tape and Bondo. The same applies to HyperWRT, though most of the trashy code there comes from the base source which is the responsibility of Linksys and their third-party vendor.

With regards to DD-WRT, I really don’t care if the exploit was released without any prior report — consider doing security audits of your own code, and stop allowing patches with hacked-up solutions. Instead, stop and think about the change in its entirety before committing.

Marvell’s faulty 88SE9123 (SATA 6G) controller

Marvell’s new 88SE9123 SATA 6G controller is apparently responsible for a number of motherboard manufacturers having to re-engineer and re-produce their upcoming Intel P55-based boards:

• SATA 6G launch delayed to do tech issues on nearly all P55 boards
• PC Perspective forum — SATA 6G delayed due to controller issues
• Faulty Marvell Chips Delay SATA 6G Launch

I’ve now added Marvell to my list of manufacturers to avoid for storage. The list is now Silicon Image (31xx series only), JMicron (a.k.a. “GIGABYTE2″ on Gigabyte boards), and Marvell. Keep ‘em coming, and keep laying off your QA staff! *sigh*

Regarding the Asus P55 series, so far I’ve seen *three* separate photos of an Asus P7P55D board, and all are completely different SATA-connector-wise:

• Board #1 — Intel connectors are red AND light blue, Marvell are white
• Board #2 — Intel connectors are light blue, Marvell are white
• Board #3 — Intel connectors are light blue, and I have no idea what’s on the brown SATA connector (7th SATA port)

Regarding a Gigabyte board (not sure what model): they planned on using two Marvell 88SE9123 controllers (each controller offers 2x SATA 6G ports), so in the PC Perspective photo of a Gigabyte board, the Intel P55 PCH SATA ports are light blue and the Marvell SATA ports are white.

I don’t know what MSI’s board looks like, so I don’t know what to tell people to avoid there.

Stick with the Intel P55 PCH SATA ports if you have one of these boards, and also disable the Marvell controller in the BIOS if possible. Take no chances.

2009/10/30 edit: Isn’t it funny how review sites don’t bother mentioning the problem? “Oops”.

FreeBSD and ZFS — NFS bug fixed on RELENG_7 amd64

I just saw this commit come through for RELENG_7:

 Edit src/sys/nfsserver/nfs_serv.c
  Add delta 1.174.2.8 2009.07.01.12.44.23 avg

The CVS commit log indicates this fixes a bug where NFS is being used on ZFS v13 exported filesystems, and the system mounting the NFS share attempts to open(2) with flags O_CREAT and O_EXCL set. The file is created — 0 bytes in size, with mode 0000 — yet the operation returns EIO. This is pretty major:

src/sys/nfsserver/nfs_serv.c

I also enjoyed reading the PR for this bug, where some developers made some amazing statements (my favourite being “use UFS2 instead of ZFS, use cp/rm instead of mv, don’t use NFS”):

http://www.freebsd.org/cgi/query-pr.cgi?pr=135412

This further validates my concern that there isn’t enough QA being done prior to code being committed to the STABLE branches. I guess no one tested ZFS v13 filesystems being exported via NFS prior to the v13 commit?

Believe me, I’m thankful that ZFS v13 is now part of STABLE — sincerely I am — but my concern isn’t limited to ZFS: it applies to FreeBSD as a whole.