Being a TA for a systems programming course in a nutshell. Except the students’ code usually doesn’t end up in any OS.
I can’t imagine there are actually many systems in production running FreeBSD with telnet installed.
Your imagination falls way short of reality then: the log mentions “Obtained from: Juniper Networks” - Junos, the OS powering Juniper devices, is based on FreeBSD and in my experience it is still not uncommon for routers and switches to be administrated via telnet (they certainly all support it).
So not only are there devices running telnet on FreeBSD in production, but they are very lucrative targets for infiltrating a network, since owning a router/switch will get you MITM capabilities.
Either Juniper is carefully reviewing every change they pull in from FreeBSD or nobody should be giving them any money.
Errrr… well, the bogus commit came from Juniper Networks upstreaming their local changes, and the attention is the number of replies by people watching FreeBSD commits.
The local change is made because of this report by hacker fantastic.
I thought the whole point of FreeBSD is that you never have to deal with upstreamed vendor code. If Juniper publish their changes why don’t they just run Linux?
They probably hired a bunch of already freebsd developers and they’re asking their employer to upstream the changes when it’s reasonable to do so.
It’s a logical business decision, too: local patches are a pain, they require merging on updates and mis-merges are a frequent cause of bugs.
Side-note: upstreaming is a bit more work than what the GPL requires. Upstream projects don’t like receiving “some unknown old version of your tree with this added work is available as a tarball here”, it usually requires some work. I’ve tried to do it in the past unsuccessfully. Even once it built and worked with the new version, I had trouble with questions about why things were done a certain way, or how to fix test failures.
My initial fix for HardenedBSD actually introduced a couple new bugs. I blame the violent food poisoning for my lack of attention to detail. ;)
But, seriously, had I felt better, I would’ve used asprintf to begin with in my fix of the vulnerable code. :)
Lesson learned: do not commit code immediately after choking on own vomit.
I was not even aware of points 4 and 9. There are lot of small things to know when coding in C. I have a love/hate relationship with it.
You know the slogan on the webpage: Only two remote holes in the default install, in a heck of a long time!
One of those was a malloc(x * y) overflow in ssh. Point 4 and 9 are very important.