Northwest Flight 253 and the “security” of it all

By now I think everybody has heard of the unsuccessful [terrorist?] attack to Northwestern Flight 253, where Umar Farouk Abdul Mutallab tried to mix bomb components about one hour before the plane landed.

We’re so used to the restrictions applied to passengers of flights, that we almost think of them as routine, while we should always think about the effectiveness of "security" measures as they are applied. The most lacking resource being often common sense.

In this case, we can already read of the next restrictive measures, on the NHS site:

The Department of Homeland Security immediately put additional screening measures into place […]

Passengers flying from international locations to U.S. destinations may notice additional security measures in place. These measures are designed to be unpredictable, so passengers should not expect to see the same thing everywhere.

So, we’ll get more restrictions, but not the same everywhere. (WTF #1)

Next, let’s see what the TSA has in mind for us:

Among other things, during the final hour of flight customers must remain seated, will not be allowed to access carry-on baggage, or have personal belongings or other items on their laps[…]

as someone else said, I’m glad that the "terrorist" didn’t try to blow himself up three or more hours before. Now, I will not be allowed to take a book (or put it away) during just the last hour of the flight, but this will surely scare all those terrorists that can act and think only during that last flight hour. (WTF #2)

I still consider myself lucky, though, because:

Effective today, the TSA has informed Northwest that travelers are not allowed to transport any liquids, gels, lotions or similar items in their carry-on luggage. This includes items such as beverages, hairspray, toothpaste and shampoo. These types of items can only be carried in checked luggage.

In the end, I do not agree with those who say that as the attack was not successful, no additional security measures would be needed. I still strongly believe that in this cases early intelligence

Mutallab’s name had surfaced earlier on at least one U.S. intelligence database, but not to the extent that he was placed on a watch list or a no-fly list.

is much more useful than a guy asking me to leave my water bottle at the security check.

In the meanwhile, it leaves me surprised that the bomber left from an airport that the TSA confirmed compliant just a month ago. Again: either the airport security failed, or the security procedures and requirements are just wrong.

Snow Leopard, ssh-agent and an everlasting memory

If you recently switched from an older (pre 10.6) version of OS X to the latest baby, and have the old habit of using ssh to connect around, you may have noticed a singular behaviour: while the older versions always asked you for a passphrase (you have a passphrase set on your private key, right?) the new OS 10.6.x does it just the first time you use it.

Now, no doubt it is handy and user-friendly and automagical and… but I feel it disturbing: if by chance I hand over the laptop to somebody for a quick glance at a web page, for example, she can use it to connect anywhere without my consent — ok, I’m oversimplifying, but you get the idea.

The mistery lies into our old friend ssh-agent: it is spawn using
/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist
[on a single line for yout copying pleasure] as a configuration file and it will cache your passphrase the first time you use ssh.
Up to here it’s fine.

What is troublesome to me is that the default cache time is unlimited (see the man page, this is the default behaviour when it is launched without specifying a “-t” option) therefore it will never forget the passphrase until I logout — being the only user of my laptop, this does not happen often.

Enter the joy of xml configuration files: edit the org.openbsd.ssh-agent.plist, and add the option to your liking, that is change this

<array>
<string>/usr/bin/ssh-agent</string>
<string>-l</string>
</array>

to something like this

<array>
<string>/usr/bin/ssh-agent</string>
<string>-l</string>
<string>-t</string>
<string>120</string>
</array>

if a couple of minutes of “grace period” suit your usage.
Then, just kill the process — it will spawn again the next time you use ssh.

[By the way:
Dear Internet, posting code like the XML up here sucks big time.
It took me more time to format the two snippets to render correctly then writing the whole post.
What do you use to ease this pain?
thank you.]

Lavori curiosi

Non per il tipo di lavoro, quanto per la curiosita` che mi suscita una job description come questa:

Title: Network Security Analyst
Category: INFORMATION SYSTEMS
Location: FORT BELVOIR, VA / USA | Sector: INFORMATION TECHNOLOGY
Description:

***Must have an active Top Secret DoD Clearance***

Works as a member of the Army Computer Emergency Response Team (ACERT) Tactical Operations Center (TOC) with specific duties as an Intrusion Specialist. […]

Oggettivamente, Northrop Grumman… Chissa` cosa vede, uno che riesce ad avere un posto come questo.

Microsoft rulez, after all (MS08-001)

More than two years ago, I was writing the first No Fills TCP RFC draft.
At that time, I wondered if one of the possible features of this new protocol could be a creative use of the RST flag (see section 4.1.1), which I mostly inteded for those Windows system administrators who had to work with a large number of machines on the same subnet.

In the version that hit the web on April, 2006 I wrote (emphasis added):

More aggressive implementation options are being considered, but some are not backward compatible despite being very useful:

  • last hop router receiving a NFRST packet SHOULD rewrite the destination address with the broadcast address of the nework of the destination host. This should achieve the effect of terminating ALL current connections over the network with the sender host.
  • the most extreme semantic of the NFRST flag would be “Reboot”: any networked host (computer, router, …) which receives such a packet MUST schedule an orderly reboot. Without any doubt this would solve many remote administration nightmares.

It is not by chance that we choose local broadcast over a multicast group as the destination of the last hop packet: most of the machines which will benefit the most of this innovative method of remote administration will be running an OS that pioneered the use of broadcast for the most inventive purposes.

But — I have to admit it — MS08-001 came in as a big surprise: Microsoft had thought better, implementing a whole sled of reboot functionalities and leaving us in the dark for two whole years!
Granted, the most exciting features (remote management and reboot) are present — as expected — only in the most recent version of its operating systems (XP, 2003, Vista), but we are used to it, aren’t we?

Please note that those with mixed XP/2003/Vista networks have to choose IGMPv3 management, while Vista-only network administrators can opt for either IGMPv3 or MLDv2 (aka CVE-2007-0069).
Fun does not stop here! Windows 2000 administrators are not left outside alone, there’s the handy RDP management (aka CVE-2007-0066) suitable for the not-so-recent enterprise.

PATCH NOW! :-)

I’m not commenting on the time frame, even if I’d like to, because it’s hard for me to determine how long these have been known but not fixed. I note that that CVE-2007-0059 was the Apple Quicktime bug discovered during the MOAB and reported on January 3, 2007 and that CVE-2007-0075 is an AspBB Remote Password Disclosure which came out on Bugtraq more or less January 4, 2007.
I have no idea if this proves anything at all. I know that CVE numbers get handed out on a first-come first-served basis, and nothing more.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close