This Day in History: Antoine de Saint-Exupéry Disappears

On July 31 in 1944 Antoine de Saint-Exupéry flew a Lockheed Lightning P-38 on a morning reconnaissance mission, despite being injured and nearly ten years over the pilot age limit. It was the last day he was seen alive. A bracelet bearing his name was later found by a fisherman offshore between Marseille and Cassis, which led to discovery of the wreckage of his plane.

Saint-Exupéry was an unfortunate pilot with many dangerous flying accidents over his career. One in particular was during a raid, an attempt to set a speed record from Paris to Hanoï, Indochine and back to Paris. Winning would have meant 150K Francs. Instead Saint-Exupéry crashed in the Sahara desert.

Besides being a pilot of adventure he also was an avid writer and had studied drawing in a Paris art school. In 1942 he wrote The Little Prince, which has been translated into more than 250 languages and is one of the most well-known books in the world. Saint-Exupéry never received any of its royalties.

It brings to mind the rash of people now posting videos and asking their fans to pay to view/support their adventures.

Imagine if Saint-Exupéry had taken a video selfie of his crash and survival in the Sahara desert and posted it straight to a sharing site, asking for funds…instead of writing a literary work of genius and seeing none of its success.

Convert Kali Linux VMDK to KVM

I was fiddling around in Ubuntu 14.04 with Docker and noticed a Kali Linux container installation was just four steps:

$ wget -qO- https://get.docker.com/ | sh
$ docker pull kalilinux/kali-linux-docker
$ docker run -t -i kalilinux/kali-linux-docker /bin/bash
# apt-get update && apt-get install metasploit

This made me curious about comparing to the VM steps. Unfortunately they still only offer a VMDK version to play with. And this made me curious about how quickly I could convert to KVM.

On my first attempt I did the setup and conversion in eight (nine if you count cleanup):

  1. Install KVM
  2. $ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils virt-goodies p7zipfull

  3. Download kali vmdk zip file
  4. $ wget https://images.kali.org/Kali-Linux-1.1.0c-vm-amd64.7z

    (Optional) Verify checksum is 1d7e835355a22e6ebdd7100fc033d6664a8981e0

    $ sha1sum Kali-Linux-1.1.0c-vm-amd64.7z

  5. Extract zip file
  6. $ 7z x Kali-Linux-1.1.0c-vm-amd64.7z
    $ cd Kali-Linux-1.1.0c-vm-amd64
    $ ll

    -rw------- 1 user user 3540451328 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s001.vmdk
    -rw------- 1 user user 1016725504 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s002.vmdk
    -rw------- 1 user user 1261895680 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s003.vmdk
    -rw------- 1 user user 1094582272 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s004.vmdk
    -rw------- 1 user user  637468672 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s005.vmdk
    -rw------- 1 user user  779747328 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s006.vmdk
    -rw------- 1 user user 1380450304 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s007.vmdk
    -rw------- 1 user user    1376256 Mar 13 03:50 Kali-Linux-1.1.0c-vm-amd64-s008.vmdk
    -rw------- 1 root root        929 Mar 13 02:56 Kali-Linux-1.1.0c-vm-amd64.vmdk
    -rw-r--r-- 1 user user          0 Mar 13 05:11 Kali-Linux-1.1.0c-vm-amd64.vmsd
    -rwxr-xr-x 1 root root       2770 Mar 13 05:11 Kali-Linux-1.1.0c-vm-amd64.vmx*
    -rw-r--r-- 1 user user        281 Mar 13 05:11 Kali-Linux-1.1.0c-vm-amd64.vmxf
    
  7. Convert ‘vmdk’ to ‘qcow2’
  8. $ qemu-img convert -f vmdk -O qcow2 Kali-Linux-1.1.0c-vm-amd64.vmdk qcow2 Kali-Linux-1.1.0c-vm-amd64.qcow2

  9. Change ownership
  10. $ sudo chown username:group Kali-Linux-1.1.0c-vm-amd64.qcow2

  11. Convert ‘vmx’ to ‘xml’
  12. $ vmware2libvirt -f Kali-Linux-1.1.0c-vm-amd64.vmx > Kali-Linux-1.1.0c-vm-amd64.xml

    (Note this utility was installed by virt-goodies. An alternative is to download just vmware2libvirt and run as “python vmware2libvirt -f Kali-Linux-1.1.0c-vm-amd64.vmx > Kali-Linux-1.1.0c-vm-amd64.xml”)

    (Optional) Create some uniqueness by replacing default values (e.g. mac address 00:0C:29:4B:9C:DF) in the xml file

    uuid
    $ uuidgen

    mac address
    $ echo 00:0C:$(dd if=/dev/urandom count=1 2>/dev/null | md5sum | sed ‘s/^\(..\)\(..\)\(..\)\(..\).*$/\1:\2:\3:\4/’)

    $ vi Kali-Linux-1.1.0c-vm-amd64.xml

  13. Create VM
  14. $ sudo ln -s /usr/bin/qemu-system-x86_64 /usr/bin/kvm
    $ virsh -c qemu:///system define Kali-Linux-1.1.0c-vm-amd64.xml

  15. Edit VM configuration to link new qcow2 file
  16. Find this section

    driver name='qemu' type='raw'
    source file='/path/Kali-Linux-1.1.0c-vm-amd64.vmdk'

    Change raw and vmdk to qcow2

    driver name='qemu' type='qcow2'
    source file='/path/Kali-Linux-1.1.0c-vm-amd64.qcow2'

  17. Start the VM
  18. $ virsh start Kali-Linux-1.1.0c-vm-amd64

  19. Delete vmdk
  20. $ rm *.v*

Howto: Install GPG on Jolla Sailfish OS

A Finnish start-up, Jolla, announced at the end of 2013 that it was producing a free and open source Sailfish OS, with an open hardware smart phone.

Here is a quick three-step guide to getting GPG installed.

STEP 1) install pinentry

You have three options:

  1. compile from source
  2. install pinentry-0.8.3-1.armv7hl.rpm
  3. use warehouse app to search for “pinentry” in OpenRepos, add “veskuh” repository and install gnupg-pinentry

STEP 2) open the terminal and install the GnuPG software

[nemo@Jolla ~]$ pkcon install gnupg2

Currently this installs version 2.0.4 with a home of ~/.gnupg

Supported algorithms:

    Pubkey: RSA, ELG, DSA
    Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
    Hash: MD5, SHA1, RIPEMD160, TIGER192, SHA256, SHA384, SHA512, SHA224
    Compression: ZIP, ZLIB, BZIP2

STEP 3) use the terminal to create a key

[nemo@Jolla ~]$ gpg2 –gen-key

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection? [Enter]
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) [Enter]
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) [Enter]
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the 
user ID from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) "
Real name: Davi Ottenheimer
Email address: davi@flyingpenguin.com
Comment:[Enter]
You selected this USER-ID:
    "Davi Ottenheimer davi@flyingpenguin.com"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Enter passphrase                            x
x                                             x
x                                             x
x Passphrase _***********_____________________x
x                                             x
x       OK           Cancel                   x
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

gpg: key XXXXXXXX marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/XXXXXXXX 2015-07-29
Key fingerprint = XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
uid Davi Ottenheimer davi@flyingpenguin.com
sub 2048g/YYYYYYYY 2015-07-29

STEP 3.5) verify key

[nemo@Jolla ~]$ gpg2 -k

/home/nemo/.gnupg/pubring.gpg
-----------------------------
pub 1024D/XXXXXXXX 2015-07-29
uid Davi Ottenheimer davi@flyingpenguin.com
sub 2048g/YYYYYYYY 2015-07-29

NOTE: you may want to move and keep your secret key on a removable storage card

We Need a Digital Right to Repair

Dan Lyke asked me a good question today, in response to my Jeep of Death blog post and tweets about patching:

So yay for sharing, but we shouldn’t normalize getting your car patches from random Internet users.

On the one hand it would be easy to agree with Dan’s point. Randomness sounds scary and untrustworthy.

On the other hand, reality says doing safe business with random people might be a reasonable and normal state of affairs. I mean imagine getting a car chip update from a random vendor, or a part to fix your suspension or brakes. Imagine getting fuel from a random vendor.

Can trust or standards of care be established to allow randomness? Yes, obviously. Hello FTC.

My response to Dan was more brief than that response, because, well, Twitter:

why not? we get other “after market” fixes for cars all the time

This does not convince Dan, unfortunately. He asks an even scarier question:

would you run random executables emailed to you by internet strangers? On your car?

I try to explain again what I said before, that we enjoy a market full of randomness that our cars execute already (e.g. gasoline, diesel…steam, vegetable oil). And that is a good thing.

YES. because i have a digital right to repair, i would. i have been doing this on my diesel chip and motorcycles for a decade.

As far as I can tell Ducati was the first to allow after-market software patches on their engines, more than fifteen years ago. I owned a 2001 motorcycle that certainly allowed for it as I patched the ECU about every year, always after-market and sometimes with a random mechanic.

The idea that we should allow any patching process to be wholly controlled by vendors and not at all by consumers or independent mechanics sounds to me like a very dangerous imbalance.

Allow me to explain in more than 140 characters:

Having the right to repair is actually an ancient fight. Anyone familiar with American political history knows horror stories about Standard Oil, Ma’ Bell, let alone GM and Ford; monopolies that have tried to shut-down innovators. Or maybe I should invoke the angry Bill Gate’s hate letter to hobbyists?

Lessons learned from history can be plenty relevant to today’s dilemmas. Consider for example the Right to Repair legislation, that that I last blogged about in 2005, pushed by the late great Senator Wellstone.

wellstone

The argument made in 2001 by Senator Wellstone was manufacturers established “unfair monopoly” by locking away essential repair information, which prohibited independent mechanics from working on cars.

Wellstone’s ‘Motor Vehicle Owners’ Right to Repair Act’ Gives Vehicle Owners the Right to Choose Where, How and by Whom To Have Repairs and Parts of Their Choice. […] This legislation allows the vehicle owners — and not the car manufacturers — to own the repair and parts information on their personal property, this time their vehicles. It simply allows motoring consumers to have the ability to choose where, how and by whom to have their vehicles repaired and to choose the replacement parts of their choice — even to work on their own vehicles if they choose.

Opposition to the legislation was not only from the big companies that would have to share information with customers. Some outside the companies also argued against transparency and self (or at least independent) services. Believe it or not, for years statements were being made about protecting “high-tech” car security (e.g. passive anti-theft devices such as smart-key and engine immobilizer) with obfuscation.

Of course we know obfuscation to be a weak argument in information security, right? Put recent news about electronic key thieves in perspective of ConsumerReports arguing in the mid 2000s that obfuscation of key technology would better protect consumers from threats…

Well the fight against consumer right to repair cars dragged on and on until Massachusetts politicians broke through the nonsense in 2012 and passed H. 4362, a Right to Repair, which was seen as a compromise that car manufacturers could swallow.

Nearly thirteen years after Wellstone introduced his bill, an important federal step was taken towards normalizing random patches.

The long fight over “right to repair” seems to be nearing an end.

For more than a decade, independent car repair chains such as Jiffy Lube and parts retailers such as AutoZone have been lobbying for laws that would give them standardized access to the diagnostic tools that automakers give their franchised dealers.

Automakers have resisted, citing the cost of software changes required to make the information more accessible.

It was because of a mostly external benefit (consumers), with mostly internal cost (automakers), that regulators had to step in to balance the economics of repair information access. Wellstone was wise to recognize consumer safety from access to information, lower-cost and faster repairs to things they own, could be more beneficial to the auto industry than higher margins.

I attempted to translate this political theory into today’s terms by Tweeting at people for a Digital Right to Repair on Android phones.

years-for-fixes

Perhaps I see the parallels today because I ran security programs at Yahoo! for mobile a decade ago and noticed parallels back then.

Phone manufacturers were slow to push security updates. Consumers were slow to pull updates. It seemed, from a cost-effective risk management view, that allowing Right to Repair to hundreds of millions of consumers we essentially would grease the wheels of progress and improvements. We anticipated patches would roll sooner and where innovation was available, because knowledge.

In other words rules that prevented understanding internals of devices also stalled understanding how to repair. To me that is a very serious security calculation.

What industry needs to discuss specifically is whether the rules to prevent understanding will unreasonably prevent safety protections from forming. Withholding information may push consumers unwittingly into an expensive and dangerous risk scenario that easily could have been avoided. Who should be held responsible when that happens?

Looking forward, the economics of IoT patching (i.e. trillions of devices needing triage) begs why not enhance sharing to leverage local resources for partnership and innovations in self-defense. As we move towards more devices needing repair, I certainly hope we do not lose sight of Wellstone’s legacy and the lessons his Act has taught us.