Archive for March, 2010


Oracle is acting rationally.

March 23, 2010

In the last post, I described what Oracle was doing and has done in relation to support customers accessing documentation for products they don’t license.  I stand by my assertion that enforcing access control in this situation is fairly trivial.  However, for Oracle, spending anything on securing access is a waste of time and money.  Here are two reasons why:

  1. Oracle suffers no harm if an actual customer reads support documentation for other products.  They cannot stop Rimini Street from accessing these materials even with strong access control…the consultants will just have to spend slightly more effort to keep up-to-date on the documentation one product at a time rather than en masse.
  2. Oracle has a business driver to eliminate the competition that Rimini Street presents.  They are going to dedicate resources to achieve this through the courts and through their business practices regardless of what ends up being their trigger event.

In my searching, I’ve not found any cases where Oracle has actually sued an end-user customer for exceeding their authorization.  I suspect that if there was never a Rimini Street or a TomorrowNow, this access control issue would not see the light of day.  Given their stance on third parties providing support for Oracle products, they’ve already allocated the money and effort to fight the competition — spending money on securing the support docs is pointless.


Access control in real life.

March 12, 2010

Rimini Street offers third-party support for Siebel, PeopleSoft, SAP, and JD Edwards software.

Oracle is suing them because they claim that Rimini is gaining access to support materials surreptitiously through Rimini clients’ online support credentials.  They sued SAP’s subsidiary TomorrowNow for the same thing in 2007.  In both cases Oracle uses the same language — that the target of the suit is involved in “[c]orporate theft on a grand scale”.

Here’s the meat from page 3 of the Rimini Street Complaint (Case 2:10-cv-106, US District Court Nevada):

Rimini Street typically logs on to Oracle’s password protected Technical Support websites using a customer credential, then downloads Software and Support Materials in excess of the customer’s authorization under its license agreement.  Sometimes Rimini Street will download hundreds or even thousands of Software and Support Materials at a time, relating to entire families of software (e.g., PeopleSoft, JDE, or Siebel) that the customer does not license and for which it has no use.

The same claim was made against SAP (March, 2007) in a San Francisco district court:

Instead, SAP employees using the log-in credentials of Oracle customers with expired or soon-to-expire support rights had, in a matter of a few days or less, accessed and copied thousands of individual Software and Support Materials.  For a significant number of these mass downloads, the users lacked any contractual right even to access, let alone copy, the Software and Support Materials.  The downloads spanned every library in the Customer Connection support website.

Rimini and TomorrowNow were using their customer’s access to download support materials from Oracle.  This is a common practice across the IT industry when consultants or contractors are supporting technology on behalf of a customer who purchased the technology.  Rimini, in the complaint, appears to have leveraged that access to download everything that the customer’s ID can touch — and customer support IDs could touch everything.  In both cases, Oracle’s complaint hinges on the claim that the agent for the customer violated authorization that has no corresponding technological control in place.  The suit against SAP/TomorrowNow was settled, and TomorrowNow no longer exists.  Given Oracle’s previous victory, a similar end is possible for Rimini.

Oracle is either trying to solve an access control deficiency through litigation, or are leaving their access control open to enable litigation.  They are clearly placing the burden of determining what a customer is licensed to download on the customer themselves.

A competent sysadmin for their support site could at the very least lock down access to materials by product in a matter of weeks, even in a dysfunctional bureaucratic environment.  The fact that they are leaving a known access control deficiency open for over three years does not imply good faith in protecting support materials on the part of Oracle.

This raises an interesting question.  Should you use strong technological controls to enforce contractual authorization, making violations a criminal matter, or should you employ lax controls and pursue violations through civil litigation?


Revisiting Python

March 10, 2010

Many years ago, I started trying to learn Python.  Within an hour, I switched to Ruby.  After two days of essentially rewriting Perl scripts in Ruby, I stuck with Perl.

That’s coming back to haunt me now.  The tools I need to use are all in Python.  Lucky for me, it’s never too late.


Mifare 1K cards in.

March 6, 2010

I just got my new S50 1K cards in today.  They come individually wrapped and ready to go.

Here you can see the chip in the corner of the card.

A random sampling of the cards read fine in the Omnikey 5321.  They appear to have a default KeyA and KeyB of 0xFFFFFFFFFFFF.  I’m going to have to tweak some python I’ve been using (RFIDIOt) so I can write the data I want to the cards.  Hopefully it will all work as planned!


Cards side-by-side

March 2, 2010

HID Prox, HID iClass, Indala ESP

From left to right, the cards are:

  • HID Prox card, clamshell form-factor
  • HID iClass card, ISO form-factor
  • Indala ESP card, clamshell form-factor

Notice the thickness of each card.  Those Indala cards were like bricks!


HID Omnikey customer service proves me wrong.

March 2, 2010

After a day of back-and-forth over the weekend, HID reps in the UK and Austria were able to assure me that the OSX drivers for the Omnikey 5321 are supposed to enable the RFID functions on the reader.  Based on their insistence, I started troubleshooting and discovered that pcscd in OSX is flaky.  It cannot handle USB reconnects or machine suspends.  If you are careful to kill pcscd before connecting the reader or waking from suspend every time, it restarts, loads the driver, and works correctly.

Although their site says that contactless cards are not supported by the OSX driver, the latest one does in fact work the same as the Linux driver with the cards I have at my disposal.  Like the Linux driver, it still does not react to EMV tokens.  I can verify that it senses and IDs iClass cards just fine.

A sincere thank-you to Markus and Mike from HID, especially to Mike for getting back to me on a Sunday.