Am I a heretic for thinking that Chrismahanakwanzaakuh isn't evil?
Call
1-888-353-7667. Be offended. Or.. don't be.
So Virgin Mobile is reacting to the whole secularization of the "holiday" season by wishing people a merry Chrismahanakwanzaakuh. Now what they're doing is just playing off what I perceive to be a sense of dissonance caused when we have to examine the intersection of habit, social construction of reality, and deeply held personal beliefs. I like to think I'm a pretty open-minded kinda guy, but I've got to tell you, saying "happy holidays" instead of "merry christmas" at work was a bit jarring for me too. But I understand the sentiment behind it. I know I'm going to have a merry christmas, but if wishing someone a "merry christmas" makes them think that I'm trying to pull a social-imperialism number on them... well.. Christmas to me is a time of expressing goodwill and finding and respecting the true God-like nature in everyone. So if saying "Christmas" to a non-christian sets them off, that's not what I'm hoping to do.
Someday I would love to live in a world where I could simply say "Merry Christmas!" to someone and if they happened not to be christian, what they would know about christianity is that we celebrate a guy who about 2000 years ago, in addition to being the son of God and all that said, something to the effect of "hey... chill out. love one-another." That Christians carry that message today and that Christmas is our way of celebrating the fact that the powerful, all-pervasive love of the creator is with us in this world. Christmas isn't about excluding non-Christians, it's about love, respect and warmth towards our fellow human beings.
I want to live in a world where each of us could wish each other a joyful Diwali, Ramadan, Chanukah, Kwanzaa, Saturnalia or Christmas (or holiday).
That being said... Virgin Mobile's Chrismahanakwanzaakuh promotion line at 1-888-353-7667 is a rather hilarious take on the whole secularization of the holiday season. I just hope I'm not a heretic for thinking it's not evil.
How Does Your 404 Page Handle "Non-Standard" Character Encodings?
Yair Amit of
Watchfire is credited for discovering a pesky little Cross Site Scripting but over at search giant
Google. The vulnerability, which was posted recently to the
Web Security Mailing List made use of lax character set enforcement in the 404 response page.
Interestingly, I talked to people in the Yahoo! Security Group a couple of years ago about exactly this sort of problem.
The vulnerability was patched in a reasonably short period of time, allowing a report to be issued after the site was fixed but still within a short "fair disclosure" window.
However.. and this is a big however.. there are still scads of sites out there that could be susceptible to this type of attack. In fact, you might want to go right now and see how your site handles this.
An archive of the original posting of this vulnerability can be found at
http://www.webappsec.org/lists/websecurity/archive/2005-12/msg00059.html, but the text of the email message has been MIMEified, which led to a little confusion when I first read it (what with equals signs being liberally sprinkled throughout the posting.) Here then is the complete posting.
//=====================>> Security Advisory <<=====================//
---------------------------------------------------------------------
XSS vulnerabilities in Google.com
---------------------------------------------------------------------
--[ Author: Yair Amit , Watchfire Corporation http://www.watchfire.com
--[ Discovery Date: 15/11/2005
--[ Initial Vendor Response: 15/11/2005
--[ Issue solved: 01/12/2005
--[ Website: www.google.com
--[ Severity: High
--[ Summary
Two XSS vulnerabilities were identified in the Google.com website,
which allow an attacker to impersonate legitimate members of Google's
services or to mount a phishing attack.
Although Google uses common XSS countermeasures, a successful attack
is possible, when using UTF-7 encoded payloads.
--[ Background
Google's URL redirection script
---------------------------------------------------------------------
The script (http://www.google.com/url?q=...) is normally used for
redirecting the browser from Google's website to other sites.
For example, the following request will redirect the browser
to http://www.watchfire.com :
- http://www.google.com/url?q=http://www.watchfire.com
When the parameter (q) is passed to the script with illegal format
(The format seems to be: http://domain), a "403 Forbidden" page
returns to the user, informing that the query was illegal.
The parameter's value appears in the html returned to the user.
If http://www.google.com/url?q=USER_INPUT is requested, the text in
the "403 Forbidden" response would be:
- "Your client does not have permission to get URL
/url?q=USER_INPUT from this server."
The server response lacks charset encoding enforcement, such as:
* Response headers: "Content-Type: text/html; charset=[encoding]".
* Response body: "<meta http-equiv="Content-Type" (...) charset=[encoding]/>".
Google's 404 NOT FOUND mechanism
---------------------------------------------------------------------
When requesting a page which doesn't exist under www.google.com, a
404 NOT FOUND response is returned to the user, with the original
path requested.
If http://www.google.com/NOTFOUND is requested, the following text
appears in the response:
"Not Found
The requested URL /NOTFOUND was not found on this server."
The server response lacks charset encoding enforcement, such as:
* Response headers: "Content-Type: text/html; charset=[encoding]".
* Response body: "<meta http-equiv="Content-Type" (...) charset=[encoding]/>".
--[ XSS vulnerabilities
While the aforementioned mechanisms (URL redirection script,
404 NOT FOUND) escape common characters used for XSS, such as <>
(triangular parenthesis) and apostrophes, it fails to handle
hazardous UTF-7 encoded payloads.
Therefore, when sending an XSS attack payload, encoded in UTF-7, the
payload will return in the response without being altered.
For the attack to succeed (script execution), the victim?s browser
should treat the XSS payload as UTF-7.
--[ IE charset encoding Auto-Selection
If 'Encoding' is set to 'Auto-Select', and Internet-Explorer finds a
UTF-7 string in the first 4096 characters of the response's body,
it will set the charset encoding to UTF-7 automatically, unless a
certain charset encoding is already enforced.
This automatic encoding selection feature makes it possible to mount
UTF-7 XSS attacks on Google.com.
--[ Solution
Google solved the aforementioned issues at 01/12/2005, by using
character encoding enforcement.
--[ Acknowledgement
The author would like to commend the Google Security Team for their
cooperation and communication regarding this vulnerability.
eInk Based eBook Reader to Ship in April '06
I've made no secret of the fact that I think that eInk is one of the coolest display technologies to come our way since india ink hit wood pulp. ( see
New eInk eBook Reader Sans DRM and
eInk Development Kit ) Thats why I'm thrilled to read that Dutch firm
iRex Technologies, BV will be releasing the
Electronic Reader "Illiad" ER 0100/xx next April.
According to iRex, the Illiad will come with a digitizer and stylus allowing the user to input comments on digital documents. It directly supports PDF, XHTML and Text (Unicode?) formats. Like traditional eBook readers, the device will connect to a host PC via USB. Unlike traditional eBook readers, however, the unit will also sport WiFi and wired ethernet network interfaces. Content can also make its way to the unit via Compact Flash and Secure Digital (SD) interfaces. Designed for extended periods between charging, the unit features an integrated rechargeable battery and a high performance-per-MIP X-Scale CPU. Together with the low power eInk display, power consumption is minimal (the company predicts 21 hours of use on a full charge.)
Comments from the company imply we won't see these things in the hands of the general public; at least not initially. iRex CEO Hans Brons comments, "We focus explicitly on B2B partners: for news, educational and professional publishers this means delivering to their audience ... " My guess is this means users of text and chart intensive high-end applications (like
Bloomberg Media or as part of the recently announced
secure mobile
environment - portable electronic device (SME-PED).) Still... if you sleuth around iRex's web site, you can find a link for the
iRex Technologies Shop, so perhaps there is a chance we'll see these under christmas^H^H^H^H^H^H^H^H^H holiday trees next year.
Though the site says nothing about Digital Rights Management, it's hard to ignore statements such as "iRex Technologies will support as many formats as possible in as open an environment as possible, respecting the rights of owners of content and IP" and "an easy delivery of the content is secured." The company also plans to deliver content via a proprietary content distribution technology termed the iRex Technologies Delivery System. This almost makes me believe the company is going to sell the units close to their cost and make money by partnering directly with content providers. Heck, maybe even
Stacking Fault could wind up distributed with this system. (Though as a fan of western civilization, if their delivery system forced DRM bits around our content, I would sort of be forced to release our content in fair-use-friendly formats.)
The company is also somewhat tight-lipped about the operating system is running on the device. This probably shouldn't be a big surprise; they're definitely focused on a product, not a platform. Still, it would be great to find there's an application development kit for the things.
More information at the company's site:
http://www.irextechnologies.com/downloads/051220-PressRelease.pdf.
Security Firm Found Doing Stupid Things
Giudance Software, a company that specializes in forensics software to analyze the effects of computer break-ins, should have known better. But for reasons that are not exactly clear, they not only violated e-commerce security guidance from credit card companies, they also violated common sense. The Washington Post has published a story that paints a very unflattering picture of the Pasadena, California based company. According to the article
Hackers Break Into Computer-Security Firm's Customer Database by Brian Krebs, the company is sending letters to 3,800 customers, breaking the bad news: "hackers got your credit card number from us."
The break-in comes to light as a result of the California Security Breach Information Act (also known as SB-1386). The act requires companies doing business in California to inform customers if, due to negligence, customers' identifying information is unintentionally revealed to third parties. Said more simply, if you collect credit card numbers, social security numbers, drivers licenses and whatnot, and you don't do enough to secure them from system attackers, then you have to send out a very embarrassing note explaining what happened.
According to reports, Guidance Software failed to properly secure credit card information given to them by customers. Most alarmingly, they retained the Card Value Verification code (the three digit security code on the card.) This is a big no-no for credit card processors. The CVV is supposed to be retained only for the amount of time required to verify a transaction; after that it's supposed to be erased from the system's memory. The company also failed to store credit card numbers in an encrypted form, leaving them exposed to any system intruder able to read the server's file-system. It's probably important to note here that storing credit cards in an encrypted database is the beginning of security process, not the end. It's required, but generally not sufficient.
Utah Digital Signature Act Headed for Extinction?
An article currently running over at
ZDNet News reports that Utah lawmakers may repeal the 1996 law regulating the issuance of digital credentials. The story,
Utah may erase early but unused e-commerce law by Anne Broache sites a falling number of CA registrations as being the impetus for pulling the law off the books. State Senator Lyle Hillyard indicates "the consensus is to repeal it [ the act ]" while Salt Lake City attorney Benjamin Wilson defends the legislation, indicating that federal and other state laws don't go as far as Utah's '96 act.
Terror Groups Cloning Phones?
Canada's
Globe and Mail newspaper published a great story last week about how ne'er-do-well terroristas are in the phone cloning game. In the story
How a terror group cloned Ted Rogers' cellphone by Peter Cheney, it is revealed that not only are Rogers Communications customers targets of phone cloning, the bad guys are going so far as to clone the phones of Roger's senior execs. The believed rationale here being that workers at
Rogers Wireless are unlikely to want to shut off Ted Rogers mobile.
The story is made public largely due to the sleuthing of Susan Drummond, a law professor at
York University's Osgoode Hall Law School. Ms. Drummond was reviewing her phone bill and was shocked to discover it was in excess of $12,000 (Canadian). (And before any of our US readers scoff at that figure, let us remember the current exchange rate is something like 85 US pennies per Canadian Dollar.) So Ms. Drummond does what any good consumer of mobile services does, she calls to complain.
The rest of the story plays out like the all too familiar customer service firestorm. Rogers contends that Ms. Drummond is liable for the full amount because she didn't report her mobile phone missing after it was stolen last year. In response, Ms. Drummond digs up some less than flattering facts about the wireless giant. In one conversation between Mr. Drummond's partner Harry Geffen and Cindy Hopper, head of Roger Wireless' security group, we learn that Hezbollah is actually targeting Rogers.
So what have we learned from this?
- If your phone gets stolen, call your carrier and have it shut off.
- Consider getting a second phone for use abroad. Or if you're using a GSM phone, consider a second SIM card for international use.
- If you're a mobile network operator, for heck's sake flip the "fraud detector" switch to the "on" position, especially for people that travel internationally.
- If you're the boss of a large wireless outfit, tell your staff you want to know if someone's cloning your phone.
- If you're the head of security for large wireless outfit, check for recording devices before talking about how Hezbollah is running amok on your network.
- If you're the head of PR for a company that's effectively turning off the security switch for senior execs and trying to bury the memos about how bad guys are exploiting this policy, start practicing the spin... stuff like this never seems to stay secret for long.
Holiday Themed Worm Infecting Windows Users
Just in time for the holidays, the good people at F-Secure are bringing tidings of... well... certainly not joy. According to F-Secure's
Virus Information Page : Dasher.A, a new worm that targets users of Microsoft's Windows 2000 Operating System. The worm exploits a vulnerability in the MS Distributed Transaction Coordinator ( described in
Microsoft Security Bulletin MS05-051. According to F-Secure's website, the worm scans random class-A addresses on port 1025 looking for a response. When found, it attempts to exploit the MSDTC vulnerability. Analysis of the code shows that after infecting a system, it attempts to connect to a central server for further instructions. Conflicting reports exist as to whether the central server is either a) not responding or b) installing a root-kit and a key-logger.
Users of Microsoft Windows products are once again encouraged to update their anti-virus software and apply the latest security patches.
One Nation Under Surveillance
James Risen and Eric Lichtblau recently penned a piece for the
New York Times in which it is asserted that the
US National Security Agency (NSA) may be listening in to some domestic communications sans court orders. For years responsibilities for eavesdropping on potential wrong-doers was split between the
Federal Bureau of Investigation (FBI) and the NSA. The FBI was focused on domestic intelligence gathering while the NSA and CIA concentrated on the external threat. This makes a little bit of sense as there are (or were) some pretty solid legal guidelines for when and how the feds can intercept communications between US citizens in the United States. Being part of the
US Department of Justice, which is responsible for pursuing violators of federal law, one would think that the FBI brass would want to avoid having to investigate themselves should they ever try to violate the law on wiretaps.
In the post 9/11 world, the legal framework established to balance the right to privacy with the reasonable prosecution of bad-guys is being eroded. We've already heard about the dramatic increase in National Security Letters, which are sort of the legal equivalent of a hall pass for wandering intelligence gathering agencies. (see the Washington Post's
The FBI's Secret Scrutiny) NSLs allow federal officials to bypass the normal requirement of obtaining a warrant before listening in to potentially private conversations or demanding surrender of sensitive information.
But all that seems to be changing; In the article,
Bush Lets U.S. Spy on Callers Without Courts, we learn that now the NSA has been given the green-light to listen in on calls where one end of the conversation is overseas. As the article says...
"This is really a sea change," said a former senior official who specializes in national security law. "It's almost a mainstay of this country that the N.S.A. only does foreign searches."
Fourth Amendment advocates like the
American Civil Liberties Union are effectively going non-linear. (see
ACLU Shocked at Bush Use of National Security Agency for Domestic Spying, Says Move Violates Constitutional Limits and Federal Laws) Caroline Fredrickson, Director of the ACLU's Washington Legislative Office is quoted as saying:
"Eavesdropping on conversations of U.S citizens and others in the United States without a court order and without complying with the procedures of the Foreign Intelligence Surveillance Act is both illegal and unconstitutional. The administration is claiming extraordinary presidential powers at the expense of civil liberties and is putting the president above the law. Congress must investigate this report thoroughly. We also call upon Attorney General Alberto Gonzales to appoint a special prosecutor to independently investigate whether crimes have been committed."
Some might be wondering why people are getting all worked up over government intelligence officials doing their job. We are, after all, a democracy; our public servants are ultimately responsible to us, the people. And how many times have I been at a dinner party and heard someone say something to the effect of... "well... I have nothing to hide, and if it makes it easier for the feds to find the bad guys, they can listen in to my phone conversations at any time."
The role of the law in this case is pretty clear. It is to prevent the executive from exercising dictatorial powers and to provide oversight by elected representatives. In general I have a pretty high regard for federal law enforcement officials; most that I've met are trying to do the best they can to grab "bad guys" moments before they commit a serious crime.
But there's been a sad history of our federal law enforcement officials and intelligence gathering organizations being directed towards dubious tasks by their political bosses. The
COINTELPRO program is a good example; in the 1950's and 60's, the FBI setup a program to investigate the activities of "subversives." Some of the groups investigated seemed like bona-fide terror groups such as the Weathermen and the Klu Klux Klan. But as is the way with things, the program was expanded to include groups such as Martin Luther King, Jr.'s Southern Christian Leadership Conference. The interesting point here is not that a government agency can be convinced to investigate an organization such as the SCLC, but that some of the political elite in the country at the time actually believed the civil rights movement was contrary to the interests of the nation.
Though our government is established by and responsible to elected representatives, we're all fallible; even elected officials can be wrong. And in a nutshell, that's why we don't like to live in a state without serious controls on the government's behavior. Our laws are put in place to limit the efficiency with which the federal executive may violate our fundamental human rights.
NSA Posts Info about "Suite B" Crypto
Readers of the old Cryptonomicon.Net site might remeber that several years ago, the NSA inked a deal with Canadian crypto developer Certicom for the rights to sublicense the firm's Point Compression and Elliptic-Curve based MQV authenticated key agreement algorithm. (see
Certicom Sells Licensing Rights to NSA) The agreement allows the NSA to grant a (potentially) royalty free license to sell products with Elliptic Curve signature and key agreement algorithms. The
NSA says they're interested in providing the technology to firms that manufacturer products to support the agency's national security mission. (This likely means you have to get a license directly from Certicom if you're building an entertainment or commercial product.)
By the way... Certicom has a nice description of ECMQV on their website in the form of
Issue 2 of Code and Cipher. ECDSA is described in ANSI X9.62, which is available from
the ANSI web site (apparently there's also a *ahem* mirror at
http://cnscenter.future.co.kr/resource/crypto/standard/ansi_x9/x9-62-09-20-98.pdf.) You can get a little more information about how the US government wants to see ECDSA used by reviewing appendix g of
FIPS 186-2 and
NIST Special Publication 800-56.
So the latest news, recently reported in
Federal Computer Week (FCW.COM) is the NSA has posted a note about
Suite B Cryptography. According to the Suite B fact-sheet, it is a subset of NIST approved algorithms for use with federal systems. So it's not so much a change of algorithms as it is a refinement of which algorithms define a common base-line of compatibility.
Near Real Time Earthquake Feed From USGS
Growing up in North Texas, my parents house was at the extreme north end of the
Balcones fault. But in Texas in the late 20th century, earthquakes were theoretical entities. While there was plenty of evidence of activity in "geologic time," insurance salesmen did not focus on earthquake policies.
So when I moved to California in the 1990's, I was happy to find a few resources at the
USGS Western Region's website to help out earthquake neophytes such as myself. The one part of the system that I really loved was the
Earthquake Hazards Program site that has
live reports of recent earthquakes around the world. California residents may be a little more interested in the
California-Nevada earthquake activity map. Having been through a few mild shakers in San Francisco and Palm Springs, I can tell you that the data from this site is very close to being real-time.
So when I discovered the new RSS interface into their earthquake activity system, I was excited with what I could do. No more parsing HTML to get to various events; right here in one easy to parse XML stream is location and magnitude information for recent quakes. While it seems they're using the dublin-core
subject tag in a non-standard way, I don't care... it's still easy to parse and interpret.
You have three RSS feeds to choose from:
1.
Quakes in the last day above Magnitude 2.5 2.
Quakes in the last week above Magnitude 2.5 3.
Quakes in the last week above Magnitude 5.0If you look at each item in the feed, you'll see that they include the time, long/lat and magnitude of each quake. This so totally calls out to be integrated with
Google Maps. Someone at the GS thinks so too... they also have Google Earth KML feeds as well. There are also feeds in CUBE and CSV format at the
Earthquake Catalogs page.
Feed the Meter via RFID
Mobile Pipeline is running an interesting story (
Wireless RFID Helps Feed Parking Meters) about technology from Vancouver based tech firm
Digital Payment Technologies.
Is Old School Tech Better?If you've parked a car at an airport or in a downtown area recently, you may be familiar with DPT's technology. Most of the items on their site are decidedly "old school." You drive into a parking space, you hike up to a central machine somewhere with bills and coins and then you're on your way. The company's "Shelby" line of parking meters even lets you pay by credit card... yawn.
But the company has been fielding parking devices that allow users to pay by mobile phone. The use experience is the would-be parker calls an 800 number, sets up an account and register a payment method such as a debit or credit card account. You then give the system your stall number and maybe how long you would like to park there and viola! presto! whammo! through the magic of wireless technology you've paid for parking! The next time you're in town, you simply call up the system, log-in and give it your parking details (like I'm in stall 15 of parking lot 9959.)
Now this is a little interesting from a use perspective. If I'm in the area of one of these devices and I absolutely, positively don't have any cash on me, I suppose I could use the phone-in system. But in an era where we keep hearing more and more about ID theft, I just get a little widged out by having to give my bank account number to yet another random company. (I should say at this point that I have no reason to believe that the network operators for this system would run their system in a way that was less secure than any other online system out there... that's not what I'm worried about. What I am worried about is the increase in the numbers of people who want continued access to my bank account. If someone doesn't have my account numbers, they can't accidentally reveal them to a malicious attacker.)
And let's review the use scenario for the phone in system.
1. As I drive up to the parking lot, I'm probably already 5 minutes late for my appointment (ask my wife, she'll confirm that I'm routinely 5-15 minutes late for everything.)
2. I get out of the car and read the 800 number off the meter.
3. I dial then number and go through the introductory message. Remember, I'm late for an appointment so it's probably the longest 20 seconds of my life.
4. I fumble through my wallet to get my credit card out to enter it into their online system; feeling a little vulnerable fumbling with my wallet in an unfamiliar parking lot, I hop back in the car and lock the doors.
5. Three minutes later, I have an account and I've paid the fare electronically.
Okay... so maybe I'm being a little hard on this system... The literature seems to imply it's really targeted for repeat customers (like university parking situations) so it's much more likely that I would have an established account. So the use experience is more like this...
1. I drive up to the parking lot, 3 minutes late for my Quantitative Methods course.
2. Out of the car I bound making note of the stall and parking lot numbers.
3. I have the parking folks on speed dial, but alas I have no coverage in this parking lot.
4. I run to the top of a nearby hill only to realize that I've forgotten my stall number.
5. Back down the hill I retrieve the stall number, hike back up the hill, and dial into the system.
6. But what's my PIN? Heck.
7. I fumble around in my backpack and startup my laptop to retrieve the email that holds my PIN (which, BTW is considered a little bit of a no-no in some security circles.)
8. Finally I have my account PIN, stall number and mobile phone coverage at the same time; I tell the system I want to purchase a little parking time.
9. I arrive 30 minutes late to class.
Compare this with...
1. I drive up to the parking lot, 3 minutes late for class.
2. I bound out of the car with a fist full of quarters.
3. I shove five quarters in the machine quickly and run off.
4. I arrive at class 7 minutes late.
But the new new parking solutions may be betterSo while I'm a big fan of putting Java on WindowsCE, the existing solution of dialing an 800 number and setting up an account just doesn't seem to me to add a whole lot of value.
But now the parking technology guys are responding to the invasion of the near-field devices.
The
902i mobile handset recently caught my eye. The thing that I found most interesting was it's integration with the
EDY (Euro-Dollar-Yen) System. EDY is the payment gateway for a RFID based digital wallet currently being fielded in Japan. Most of the documentation is in Japanese, but you can get a general idea of the system from the following
EDY HowTo Page.
So now we're looking at a whole new ball-game. Instead of setting up an account specifically for parking, I can use my mobile wallet to auto-magically feed the meter. Hop out of the car, wave my phone in front of the meter, enter my PIN on the phone keypad, and Viola!
That's actually compelling.
