If Verisign wants to be pricks about this (and they have repeatedly demonstrated a propensity for being such) then they will retaliate.
Consider this phrase in ICANN's letter:
"... this a formal demand to return the operation of the.com and.net domains to their state before the 15 September changes..."
This could be interpreted by Verisgin to undo all changes since the 15th of Sept. Verisign could easily roll back any.com and.net registrations since the 15th of Sept and then claim "ICANN ordered us to!".
When I said my servers were running a daemon that allowed remote root logins, I wasn't meaning in the sense that they were open to Internet at large.
All of the servers I was dealing with were on our internal LAN and behind our firewall. The application in question was a daemon that was supposed to listen on a given port. In fact, we had scans set up to monitor and alert us if the service went down. So our portscans showed it as a listening port as it should have. We would have had to put a sniffer against it to see that it was passing traffic that it wasn't supposed to.
I am not saying I couldn't have detected that the daemon was doing a bit more than it ought to but it wasn't quite as simple as you suggest.
I saw first hand how back dooring software could provide job security for
one developer.
I worked at a company that produced some very complex financial and
utilities management software. They needed a way to have these
two applications talk to each other and their solution was a daemon to
act as a conduit between the two. Since it had to assume user privs the
daemon was set to run root suid.
The code had been in production for quite some time when it was assigned
to developer to maintain. The code was a mess (it had been written
originally by people unfamiliar with programming in the Un*x
environment). The developer was tasked with cleaning up the code if he
could. Since they were very busy there was little or no supervision
over him. As long as the daemon worked everyone was happy.
Eventually the development department decided to restructure and
investigated letting this guy go. He had a reputation of being a bit of
a hacker so they came to me (I being the Un*x/Network admin at the time) to see how
we might protect ourselves from reprisals should he be let go.
I was fairly confident that my systems were tight. The biggest weakness
as I saw it was this daemon. So I checked out the source code and
started going through it. As I did, I discovered that this simple
daemon had developed some new and interesting features. Along with it's
normal duties, it also doubled as a telnet daemon (you could telnet to
the listening port and login just as in telnet - except this one would
ignore/etc/securetty thus allowing remote root logins over an
unencrypted protocol). Another feature was it's ability to tunnel other
ports through it's own listening port.
The code was too convoluted for me to get a complete grasp on it in the
time alloted. I went back to the VP of development, pointed out what I
had found, and suggested that he would need to have every piece of code
this guy had worked on audited to make sure it was clear of back doors.
He visibly paled. The developer in question had been there for over 5
years by this point and had touched nearly everything at one time or
another.
In the end they simply moved him to another department (he is still
there as far as I know). They felt it was too cost prohibitive (and
dangerous) to let him go.
They never did tell their customers about these gaping security holes either.
Lessons learned:
Never trust code you haven't audited yourself. I had a daemon
running on my servers that was allowing remote root logins and I
didn't even know it.
This brings up another point. I think they may be facing a bit of a backlash against all the hype the product received before it was released. The media was flooded with reports and speculation about "Ginger" and the "Thing" weeks before anyone even knew what it was. They were saying it was going to revolutionize transportation. When it was finally revealed, I for one felt a bit cheated to find it ammounted to little more than an expensive scooter for adults. Cool? Yes. Revolutionary? I don't think so.
Slashdot Mirror
"... this a formal demand to return the operation of the .com and .net domains to their state before the 15 September changes ..."
This could be interpreted by Verisgin to undo all changes since the 15th of Sept. Verisign could easily roll back any .com and .net registrations since the 15th of Sept and then claim "ICANN ordered us to!".
--
DaTreeBear
When I said my servers were running a daemon that allowed remote root logins, I wasn't meaning in the sense that they were open to Internet at large.
All of the servers I was dealing with were on our internal LAN and behind our firewall. The application in question was a daemon that was supposed to listen on a given port. In fact, we had scans set up to monitor and alert us if the service went down. So our portscans showed it as a listening port as it should have. We would have had to put a sniffer against it to see that it was passing traffic that it wasn't supposed to.
I am not saying I couldn't have detected that the daemon was doing a bit more than it ought to but it wasn't quite as simple as you suggest.
I saw first hand how back dooring software could provide job security for one developer.
I worked at a company that produced some very complex financial and utilities management software. They needed a way to have these two applications talk to each other and their solution was a daemon to act as a conduit between the two. Since it had to assume user privs the daemon was set to run root suid.
The code had been in production for quite some time when it was assigned to developer to maintain. The code was a mess (it had been written originally by people unfamiliar with programming in the Un*x environment). The developer was tasked with cleaning up the code if he could. Since they were very busy there was little or no supervision over him. As long as the daemon worked everyone was happy.
Eventually the development department decided to restructure and investigated letting this guy go. He had a reputation of being a bit of a hacker so they came to me (I being the Un*x/Network admin at the time) to see how we might protect ourselves from reprisals should he be let go.
I was fairly confident that my systems were tight. The biggest weakness as I saw it was this daemon. So I checked out the source code and started going through it. As I did, I discovered that this simple daemon had developed some new and interesting features. Along with it's normal duties, it also doubled as a telnet daemon (you could telnet to the listening port and login just as in telnet - except this one would ignore /etc/securetty thus allowing remote root logins over an
unencrypted protocol). Another feature was it's ability to tunnel other
ports through it's own listening port.
The code was too convoluted for me to get a complete grasp on it in the time alloted. I went back to the VP of development, pointed out what I had found, and suggested that he would need to have every piece of code this guy had worked on audited to make sure it was clear of back doors. He visibly paled. The developer in question had been there for over 5 years by this point and had touched nearly everything at one time or another.
In the end they simply moved him to another department (he is still there as far as I know). They felt it was too cost prohibitive (and dangerous) to let him go.
They never did tell their customers about these gaping security holes either.
Lessons learned:
This brings up another point. I think they may be facing a bit of a backlash against all the hype the product received before it was released. The media was flooded with reports and speculation about "Ginger" and the "Thing" weeks before anyone even knew what it was. They were saying it was going to revolutionize transportation. When it was finally revealed, I for one felt a bit cheated to find it ammounted to little more than an expensive scooter for adults. Cool? Yes. Revolutionary? I don't think so.