Slashdot Mirror

fsagx writes "Steve Gibson has proposed a new standard method for website authentication. The SQRL system (pronounced 'squirrel') eliminates problems inherent in traditional login techniques. The website's login presents a QR code containing the URL of its authentication service, plus a nonce. The user's smartphone signs the login URL using a private key derived from its master secret and the URL's domain name. The Smartphone sends the matching public key to identify the user, and the signature to authenticate it. It may be used alongside of traditional username/password to ease adoption."

An anonymous reader writes "Steve Gibson alleges that the WMF vulnerability in Windows was neither a bug, nor a feature designed without security in mind, but was actually an intentionally placed backdoor. In a more detailed explanation, Gibson explains that the way SetAbortProc works in metafiles does not bear even the slightest resemblance to the way it works when used by a program while printing. Based on the information presented, it really does look like an intentional backdoor." There's a transcript available of the 'Security Now!' podcast where Gibson discusses this.

An anonymous reader writes "Steve Gibson alleges that the WMF vulnerability in Windows was neither a bug, nor a feature designed without security in mind, but was actually an intentionally placed backdoor. In a more detailed explanation, Gibson explains that the way SetAbortProc works in metafiles does not bear even the slightest resemblance to the way it works when used by a program while printing. Based on the information presented, it really does look like an intentional backdoor." There's a transcript available of the 'Security Now!' podcast where Gibson discusses this.

An anonymous reader writes "Steve Gibson alleges that the WMF vulnerability in Windows was neither a bug, nor a feature designed without security in mind, but was actually an intentionally placed backdoor. In a more detailed explanation, Gibson explains that the way SetAbortProc works in metafiles does not bear even the slightest resemblance to the way it works when used by a program while printing. Based on the information presented, it really does look like an intentional backdoor." There's a transcript available of the 'Security Now!' podcast where Gibson discusses this.

An anonymous reader writes "ZoneAlarm is getting ready to announce version 5 of its security software firewall, ZoneAlarm. Though there are a few changes that are presently available on the new beta, this review mentions that there are still many security issues to resolve. Grc.com scan reveals that ZoneAlarm Beta 5 failed to close port 25 and fails to give useful information to the user about possible security services being shut off."

RayMarron writes "It seems that NAI's IP lawyers have been billing some hours recently by sending nastygrams asking companies/individuals to stop using their trademarked term 'Sniffer.' Steve Gibson of Gibson Research Corporation has received one. The full text is posted on his news server, and I'm sure one of our readers will post it here. Or visit news.grc.com, grc.news and grc.news.feedback groups. A student at Stanford received one as well and forwarded it to the faculty to handle. Both Gibson (relating a conversation with his IP attorneys) and Stanford's reply seem to agree that 'sniffer' is too generic a term to be a viable trademark and can't be effectively enforced. Is there an IP lawyer in the house?"

An Anonymous Coward asks: "Here at work for internet connectivity, we share a Cisco 2600 router with the administrative folks in the other half of the building. Our development network is isolated from theirs, safely behind a Debain firewall--we just show up as one IP with _very_ few ports open. The Cisco connects directly into a Linksys DSL router, which is *supposed* to be providing NAT for both of our networks. Instead, it's acting needlessly as an extra hub, with the incoming feed plugged into its port 2 and the outgoing feed in port 3. The feed from port 3 plugs into a 24-port hub, which connects all of the admin workstations and our Debian box. Each workstation, in turn, has a static IP (we have one too). This is due to a variety of reasons--so we've been told--but what it boils down to is the incompetence of the 'Microsoft Certified (w/Internet) Network Engineer,' who's responsible for the routers, the administrative network, and their Windows 2000 corporate webserver." Now, the workplace is left with no firewall and a Network Engineer that is downplaying the problem to the higher-ups. What would be the best way to communicate that there really is a problem?

"I went up the chain and explained the problem to my boss. He was horrified. He took it to his boss (who also happens to be in charge of said Network Engineer). The result was less-than spectacular. My boss' boss came out, with The Engineer in tow, who after fiddling with things for a while, proclaimed everything to be 'locked down,' and then they left. What we later discovered was that she'd only closed down a few of the webserver's non-essential ports and had done nothing about the Linksys firewall situation. But in the process, she'd managed to convince our collective higher-ups that the problem wasn't as big as we (read: the lowly, know-nothing, software developers) had made it all out to be and now nobody wants to hear a word about it. In other words, they have NO firewall at all, and we've been unable to convince them that this is a Bad Thing(tm).

Since The Engineer and her boss have always tended to be reactive, rather than proactive, I logged onto Steve Gibson's Leak Test from an admin workstation and showed them the results. Unfortunately, this 'parlor trick' failed to generate much in the way of enthusiasm. So what I'm looking for are (mostly) non-destructive suggestions to alert them to the dangers of their network configuration. Short of posting their IP's in a #skript_kiddie_channel and daring them to trash everything, how should I bring it to their attention in a, shall we say, meaningful way?"

Brian Stretch writes: "The Code Red II worm was unleashed early this morning and appears to be very different than the original and far more dangerous. CR2 infected servers only attack servers within their Class A address block and their Class B address block in particular: since 9:11am EST I've logged 148 CR2 attack attempts, 89 of which are from within my Class B subnet, suggesting that only servers within Class A networks that were deliberately seeded are being attacked. The 24.x.x.x range is one of the hardest hit, and as before, it's folks with cable modems and DSL connections that are providing the most victims." Several @home customers have written about slowed service today, but they're definitely not alone.

Brian Stretch writes: "The Code Red II worm was unleashed early this morning and appears to be very different than the original and far more dangerous. CR2 infected servers only attack servers within their Class A address block and their Class B address block in particular: since 9:11am EST I've logged 148 CR2 attack attempts, 89 of which are from within my Class B subnet, suggesting that only servers within Class A networks that were deliberately seeded are being attacked. The 24.x.x.x range is one of the hardest hit, and as before, it's folks with cable modems and DSL connections that are providing the most victims." Several @home customers have written about slowed service today, but they're definitely not alone.

MartinB writes: "Following a recent spate of DDoS attacks on his grc.com (home of Shields UP!), Steve Gibson investigated, finding a network of compromised IRC bots being used to flood vulnerable targets. Surprisingly, the thing which saved him is Win 9x's non-standard implementation of Sockets, making it impossible to spoof IPs. However, he warns, even consumer versions of WinXP won't have this safety 'feature'. Is there time to prevent this? Is implementing the standard always A Good Thing?" Gibson uses too many exclamation points in his article. But it's still interesting, if only to note the number of exploited personal machines on cable modems.

MartinB writes: "Following a recent spate of DDoS attacks on his grc.com (home of Shields UP!), Steve Gibson investigated, finding a network of compromised IRC bots being used to flood vulnerable targets. Surprisingly, the thing which saved him is Win 9x's non-standard implementation of Sockets, making it impossible to spoof IPs. However, he warns, even consumer versions of WinXP won't have this safety 'feature'. Is there time to prevent this? Is implementing the standard always A Good Thing?" Gibson uses too many exclamation points in his article. But it's still interesting, if only to note the number of exploited personal machines on cable modems.

MartinB writes: "Following a recent spate of DDoS attacks on his grc.com (home of Shields UP!), Steve Gibson investigated, finding a network of compromised IRC bots being used to flood vulnerable targets. Surprisingly, the thing which saved him is Win 9x's non-standard implementation of Sockets, making it impossible to spoof IPs. However, he warns, even consumer versions of WinXP won't have this safety 'feature'. Is there time to prevent this? Is implementing the standard always A Good Thing?" Gibson uses too many exclamation points in his article. But it's still interesting, if only to note the number of exploited personal machines on cable modems.

HerrHair had the first reader submission of this, but it took a few days to look into it. If you use Earthlink's customized browser/email/chat/kitchen sink application, which Earthlink recommends for all of its new customers, you are sending an extra HTTP header called HTTP_ELNSB50 with every HTTP request (every download of a file or image), and the data for this header is a lengthy alphanumeric string, which readers took to be a unique ID of some sort. This does not appear to be the case.

Steve Gibson was apparently the first one to look into this browser serial number. I'm a little hesitant to link to that page, since its contents have changed dramatically twice in the last 24 hours. Gibson initially had a page claiming it was privacy-invading unique ID. He changed it to include a disclaimer in a large red box, and has now changed it again to display the information Earthlink provided about the serial number. Earthlink provided much the same information to slashdot after our query.

The header information sent is similar to the codes below. Depending on how logging is set up on a given webserver, they may or may not be logged, but enough server logs are accessible across the net that typing ELNSB50 into any search engine will find examples. (ELNSB50, by the way, apparently stands for "Earthlink Sandbox 5.0".)

ELNSB50::0000411003200258029a012800000000050300280 0000000
ELNSB50::0000411003200258029a012d000000000503002a0 0000000
ELNSB50::0000411003200258029a013200000000050300280 0000000
ELNSB50::0000411003200258029a0132000000000503002a0 0000000
ELNSB50::0000411003200258029a013b000000000503002a0 0000000
ELNSB50::0000411003200258029a013d000000000503002a0 0000000
ELNSB50::0000411003200258029a014700000000050300280 0000000

Even a cursory examination should show that these numbers don't have enough uniqueness to be globally unique IDs. Microsoft's GUID had 128 bits; a good hash function might have 160 bits; those serial numbers, culled from widely scattered machines, aren't unique enough.

This is what Earthlink sent us about the codes:

reserved: 14 future growth monitorDepth: 8 monitor bit depth browserFontSize: 3 browser font -- small to large connectionSpeed: 3 One of 4 categories connectionType: 4 Modem, high speed, etc. monitorHorz: 16 horizontal area monitorVert: 16 max vertical area browserViewHorz: 16 views horizontal area browserViewVert: 16 views vertical area popID: 32 numerical POP ID sandboxVersion: 32 what version of the sandbox sent this?

Most items should be self-explanatory. ConnectionSpeed has four possible values: slow dialup (<56K), fast dialup (56K), slow broadband, and fast broadband. The POP ID refers to which of Earthlink's Point-of-Presences you are dialed up to - which bank of modems you called. The rest should be clear. If you assume the codes are a number in hexidecimal, and the above are the number of bits dedicated to each bit of information, they appear to agree well. This table differs slightly from Steve Gibson's version. The differences appear to be minor and reconcilable - Earthlink doesn't seem to like the use of the word "Sandbox" in external publications, but it's their own term for their software and it seems quite appropriate: a closed environment which has all the toys you need and which you don't want to/are not able to escape from. (A screenshot of Earthlink's Sandbox is available.)

While I was looking into this, I also noted (Ethereal strikes again) that Earthlink's Sandbox sends a good chunk of data back to Earthlink's servers upon initial installation - this data is PGP-encrypted, or at least it is preceded by a header indicating that it is. This data is sent whether or not the user is signing up for a new account or just re-installing the software on an old machine. There is no easy way to determine what information is being sent back without performing a comprehensive disassembly of the software. As of press time, Earthlink has not provided any information about what is being sent to Earthlink's servers when their software is installed.

So, there you have it. Is Earthlink's code a unique ID? Apparently not. Does it reveal more information about you when you are browsing the web than is revealed by any other web browser? Yes. Can you turn it off? No, but you could use another browser. Will 99% of Earthlink's users ever know about it? No.

rednax asks: "We see a lot of discussion on /. regarding many 'high level' languages (PERL, Python and JAVA for example are all well covered) rather than assembly language. There are a few exceptions such as this discussion from waaaay back when, which touched on it. Assembly level languages obviously have a place in all systems at the lowest level to provide basic services, but what about other areas. Obviously there are trade offs. Speed and compact object code are the two main arguments for assembler, but how much do these matter when we can get 1GHz processors, and large amounts of RAM? How many /.ers do use assembler, and what for?"

"Obviously assembly code is needed in embedded systems - I do not mean embedded Linux systems here, but rather the specialised, dedicated processor systems that do control work. Gibson research is one of the few advocates for programming down at the bare metal level that I have seen recently, and I think his products show what can be done in an incredibly small space, when Assembler is used. This too is one of his works."

rednax asks: "We see a lot of discussion on /. regarding many 'high level' languages (PERL, Python and JAVA for example are all well covered) rather than assembly language. There are a few exceptions such as this discussion from waaaay back when, which touched on it. Assembly level languages obviously have a place in all systems at the lowest level to provide basic services, but what about other areas. Obviously there are trade offs. Speed and compact object code are the two main arguments for assembler, but how much do these matter when we can get 1GHz processors, and large amounts of RAM? How many /.ers do use assembler, and what for?"

"Obviously assembly code is needed in embedded systems - I do not mean embedded Linux systems here, but rather the specialised, dedicated processor systems that do control work. Gibson research is one of the few advocates for programming down at the bare metal level that I have seen recently, and I think his products show what can be done in an incredibly small space, when Assembler is used. This too is one of his works."

An anonymous reader writes that "Steve Gibson is working on something called NanoProbe technology. He describes it as advanced remote Internet security testing. " Lots of interesting stuff to think about in there (despite the fact that he says its designed for windows). Its quite technical, and apparently moving fairly quickly forward.

Steve Gibson of grc.com claims to have come up with a way of preventing DoS attacks by spoofed SYN flooding. The idea is that no information is retained by the server after the initial SYN is received. The server's resources aren't used until the ACK is received from the client (which must have a real address to receive the reply from the server). The SYN/ACK back from the server is encrypted to prevent "ACK flooding." It can be implemented in a way that is transparent to clients, so only servers need alteration. I'm skeptical (and this only solved one kind of DoS), but it's worth looking at.

Steve Gibson of grc.com claims to have come up with a way of preventing DoS attacks by spoofed SYN flooding. The idea is that no information is retained by the server after the initial SYN is received. The server's resources aren't used until the ACK is received from the client (which must have a real address to receive the reply from the server). The SYN/ACK back from the server is encrypted to prevent "ACK flooding." It can be implemented in a way that is transparent to clients, so only servers need alteration. I'm skeptical (and this only solved one kind of DoS), but it's worth looking at.

Martin Hock writes " This guy, Steve Gibson, who is phat enough to write everything in assembly language, but not phat enough to run Linux, has created a nifty freeware (beer, not speech) program for Windoze called Free & Clear that demos the way Microsoft's ClearType "may" work by employing color fringing. Only interesting if you have a color LCD display, or possibly if you have an extremely precise aperture grill. On my Libretto, it's pretty funky fresh. He claims that it works with Virtual PC, but I'd be impressed if someone got it to work under Wine, because we all know how much X loves fonts... I've given it a quick spin with the Non-Emulator myself and it looks trashy. " Is anyone up to porting this bugger? The page is excellent because it explains all sorts of interesting things about the technology in question, including the fact that it has been around for 22 years longer than Microsoft seems to want us to believe.