The service will cost first-class passengers not a thing, but coach will pay €6.50 (US$10) per hour or €13 (US$20) for an entire trip. The train operator is initially equipping 7 trains, but will complete work on all 26 trains by October. Trip durations run from 1 hour 20 minutes to 3 hours.

Most impressively, the consortium that built the system is using a pretty modest antenna that moves automatically to stay in contact with the satellite. It's 80 by 72 cm (31.5 by 28.3 inches), and plans are to shrink that to something 2/3rds the height when a new dish is certified. Ultimately, IDG News Service reports, the group plans to use 3 cm (1 in) high phased-array antennas that would cover the train's roof. Very, very clever, as it jettisons any moving parts.

Three companies worked on the technology: Telenet, handling the billing and authentication, is a Belgian ISP that also runs hotspots; Nokia Siemens is a well-known systems integrator, and is providing some gear and handling installation and integration; 21Net, perhaps the least-well known partner, has the satellite technology.

This project dates back to at least 25-April-2005, a point at which 21Net and Nokia Siemens announced a successful test on the Thalys run from Brussels to Paris.

For those who don't know, Barracuda is involved in a wicked patent fight with Trend Micro over the use of Clam AV gateway anti-virus. It seems according to a 1995 patent issued to Trend Micro, they claim that virtually all gateway AV that removes viruses as they move through a SMTP or FTP proxy servers are covered under this patent. Barracuda uses the popular, open source Clam AV product in their appliances and Trend says their use violates the patent.  Evidently this little tiff has been going on for some time, with Trend filing a complaint with the US International Trade Commission in addition to the conventional law suits. Trend also claims that their position here is well established and several previous suits and claims have been upheld including a settlement with Fortinet (does Fortinet use Clam AV too?).

My position is that this is a perfect case of why so much of this patent  stuff is just full of beans.  How can Trend have a patent on gateway AV. If they do why are they wasting time piddling around with the likes of Barracuda.  Why don't they go after the big boys like Symantec or McAfee? Something tells me there is a reason why Trend does not.  Either they are not as confident in their claim as they make out to be or Symantec and McAfee know something that the rest of us don't.  Maybe they have proof of prior use before the patent was filed. 

Many in the open source community including Richard Stallman (no surprise there) and Eben Moglen of the Software Freedom Law Center have joined in to support Barracuda in this legal battle.  Barracuda is in fact very much painting this as an attack on open source and looking to the community for support.  Trend for their part says that this is not about open source or even Clam AV, it is about filtering virus pursuant to the techniques they patented.  Again, my view is I don't think Barracuda is doing anything different than other ClamAV users.  Though Trend's claims may go to all gateway AVs, clearly this is about Barracuda using Clam and about Clam. 

So here is my question: Why haven't we heard from the owners of ClamAV. Sourcefire bought them in August I thought.  This could effect them as much as anyone. They are big supporters of open source and as a public company can bring resources to bear on this.  Why has Marty, Wayne and gang been silent on this.  I would think they should be leading the charge here and standing up for their product.  Leaving Dean Drako and Barracuda to fight this fight on behalf of the Clam community is not fair and also could have repercussions down the road to Sourcefire without them being involved. Is it that Barracuda is not paying for their use of Clam?  I don't know what the answer is but it will be interesting how this plays out.

1. JDK. In May 2007, I released details on an interesting bug in the ICC profile parser in Sun's JDK. The bug is particularly interesting because it could be exploited by an evil image. Most previous JDK bugs involve a user having to run a whole evil applet. The key parts of code which demonstrate the bug are as follows:
   

   
TagOffset = SpGetUInt32 (&Ptr);
if (ProfileSize < TagOffset)
  return SpStatBadProfileDir;
...
TagSize = SpGetUInt32 (&Ptr);
if (ProfileSize < TagOffset + TagSize)
  return SpStatBadProfileDir;
...
Ptr = (KpInt32_t *) malloc ((unsigned int)numBytes+HEADER);


   
   Both TagSize and TagOffset are untrusted unsigned 32-bit values pulled out of images being parsed. They are added together, causing a classic integer overflow condition and the bypass of the size check. A subsequent additional integer overflow in the allocation of a buffer leads to a heap-based buffer overflow.


2. gunzip. In September 2006, my colleague Tavis Ormandy reported some interesting vulnerabilities in the gunzip decompressor. They were triggered when an evil compressed archive is decompressed. A lot of programs will automatically pass compressed data through gunzip, making it an interesting attack. The key parts of the code which demonstrate one of the bugs are as follows:
   

   
ush count[17], weight[17], start[18], *p;
...
for (i = 0; i < (unsigned)nchar; i++) count[bitlen[i]]++;


   
   Here, the stack-based array "count" is indexed by values in the "bitlen" array. These values are under the control of data in the incoming untrusted compressed data, and were not checked for being within the bounds of the "count" array. This led to corruption of data on the stack.



3. libtiff. In August 2006, Tavis reported a range of security vulnerabilities in the libtiff image parsing library. A lot of image manipulation programs and services will be using libtiff if they handle TIFF format files. So, an evil TIFF file could compromise a lot of desktops or even servers. The key parts of the code which demonstrate one of the bugs are as follows:
   

   
if (sp->cinfo.d.image_width != segment_width ||
    sp->cinfo.d.image_height != segment_height) {
  TIFFWarningExt(tif->tif_clientdata, module,
    "Improper JPEG strip/tile size, expected %dx%d, got %dx%d",


   
   Here, a TIFF file containing a JPEG image is being processed. In this case, both the TIFF header and the embedded JPEG image contain their own copies of the width and height of the image in pixels. This check above notices when these values differ, issues a warning, and continues. The destination buffer for the pixels is allocated based on the TIFF header values, and it is filled based on the JPEG values. This leads to a buffer overflow if a malicious image file contains a JPEG with larger dimensions than those in the TIFF header. Presumably the intent here was to support broken files where the embedded JPEG had smaller dimensions than those in the TIFF header. However, the consequences of larger dimensions that those in the TIFF header had not been considered.