Este post también está escrito en español.

If you follow me on Twitter/Facebook, you probably know that I went to Gothenburg, Sweden, during my last trip to Europe. But you probably don’t know what I did in such remote city.

Few months ago, I applied to a PhD student position at Chalmers. I was lucky enough to be shortlisted, so I went to some in-situ interviews. And, incredibly, I have been accepted! :-)

Chalmers is a TOP 100 university. Most of the papers I read during the last months has been written by Chalmers researchers and for me is a great honor to be part of an academic institution with such prestige.

I’m going to move to the nice Gothenburg city in August. And I’m happy :)

During the last months and have been reading a lot about information flow analysis, with the remarkable Eduardo Bonelli‘s guidance.

Some months ago, as an exercise, I wrote two analyzers for a really short command set of Python (while, if and assign). Before remove that directory, it occurred to me that may exists a remote possibility that someone might find it interesting. So here it is, with a quick and dirty introduction to secure information flow.

The goal, in short words, is to avoid that variables tagged as secret (high confidential level) doesn’t leak to public variables (low confidential level). This may happen in two ways:

• Explicit: A high variable is assigned to a low variable

public:=secret

• Implicit: A low variable content depends on the content of a high variable

if secret == true
then public:=true
else public:=false

If there is no leak, we said that the code satisfies non-interference (wikipedia link). You can learn more about secure information flow analysis in the web. In my humble opinion, this is a good introduction.

A typical way (certainly not the only one) to detect these leaks is with type systems. This was the approach in both analyzers. The first one is a sort of an implementation of a fundation paper, by Volpano et.al.. I made an algorithm version (probably wrong) of the typing rules exposed in the paper. The code is here. This type of analyzers are called Denning-style, because Denning and Denning introduced those concepts in a 1977 paper.

The second analyzer (the code is here) is based on the formalism presented by Hunt and Sands in this paper. It’s a dynamic analyzer (Denning-style analyzers are static), which means that the non-interference can be broken in subprograms and still be good as a whole. This may be a little tricky. For example, this code is secure (the leak was overwritten with a 0) even when a subprogram (without the last line) is insecure:
public:=secret
public:=0

Anyway, that’s all for now. The analyzers are written in Python, using the Abstract Syntax Trees module and python-lattice (yes, this is what that stupid library is for). If you want to play more, here is a tarball with the code, the papers and few examples to analyze.

In the context of my recent readings about Information Flow analysis, I wrote a little (tiny) Python module to operate elements of a finite lattice. Here is the code and usage tutorial. Comments are welcome. Patches to my broken English in the main page are very welcome.

Este es un delayed post, dado que DebConf10 New York City terminó hace 3 días. Aunque más tarde de lo esperado, no quería dejar pasar la oportunidad de comentar lo bien que la pasé. Siempre es agradable encontrarse con amigos.
Si bien pude dedicar mucho tiempo al security team (generé 3 nuevos DSA aunque, de momento, se ha publicado uno solo), me quedaron muchísimas cosas pendientes por hacer. Además tengo muchas nuevas ideas que me gustaría concretar durante el próximo año.

Entre los pendientes está el de subir fotos, para variar. Así que stay tunned! Para los ansiosos, hay publicadas fotos de otros asistentes aquí. También están disponibles las versiones preliminares de las charlas, donde se me puede ver dado una Lightning Talk, acerca de un prototipo para documentar workflows que se me ocurrió hace unos meses (minuto 10:40 de este video).

I have a new guest in my apartment. Give a warm welcome to the Adrianus Johannes Wilhelmus Duijvestijn‘s spirit.

Thanks a lot to Bartu and Rezlaj, who carried out the necessary seance that make this possible.

The complete photo set is here. If you do not have the slightest idea of what I’m talking about, take a look to Wikipedia or my previous post (Spanish only).

(esta entrada también está disponible en Español)

I happy to announce that I bought the tickets, so…

• AV88 EZE-BOG: 6h 30m
• Waiting at BOG: 10h 50m
• AV20 BOG-JFK: 5h 35m
• AV21 JFK-BOG: 6h 00m
• Waiting at BOG: 9h 10m
• AV87 BOG-EZE: 6h 15m

Summarizing, almost half of the trip is waiting… :P

Ladies and gentlemen, with you…

my (first) nephew :)

UPDATE Tue, 09 Mar 2010 15:05:51 -0300: According to this, is a “he” (henceforth Gregorio).

Since I am a housewife (i.e. since I live on my own) my concerns have been extended to foreign horizons, such as taming dust and lint. All my network devices and wires has a particular magnetism for them. To make things worse, the devices cleaning is quiet hard.

So, I decide to boxing them. All you need is a big tupperware and few rubber bands. Here is the process to build it:

Este post también está escrito en español aquí.

Privacy at Facebook is heavy-duty. As a big fan of the Worlds Collide Theory I hate be tagged compulsively. I would like to select in which photos appear in my profile and feed. Since I couldn’t find that option in the setting menu, I looked for the answer in my favorite scripting language: Python.

This 60-lines-long script removes your tag from the latests photos where you has been labelled. You can download it from here. You may run it hourly (or every 15 minutes, or every 5 minutes, depends how paranoid you are) via cron or whatever.

Any improvement is welcome. It probably runs on Windows too. If you managed to do it, leave a comment for the others.

NEW VERSION! (available here).

When your laptop is being repaired (and it’s still there, since August 28) you need imaginative ways to be connected.

Here is my Nokia N800 as something near to a desktop computer.

Just few notices:

• life battery is really short when you plug too many things to the USB interface.
• usbcontrol rules
• solder a female-female USB adapter is easy and funny (it came from a broken motherboard)
• after some weeks using Maemo, ideas about developing applications to it come to my mind
• the mail client and the browser included with Maemo suck
• my ocular health is being damaged

If I say “I got the third place in a scholarship application”, it doesn’t look bad.

But there is money only for the first two persons. Sometimes, close is not enough. So, without money, I won’t be able to study in Europe… damn…

Maybe next year… maybe not.

Note: The application was, as you can see, for a doctoral scholarship in Spain… my broken English has no effect here…

Finally, my sis caught someone for ever…

Only 3 things to say:

• the wedding gonna be on December 8th
• Congratulations Pato! Be happy by sharing your happiness
• My deepest sympathies Seba :P

Some days ago, my new camera arrived. I bougth it via Amazon and the parents of a friend brought it to my country.

The selected model was a Canon PowerShot SX110 IS. My last camera was a Canon PowerShot A700. It has been in service since April 2006, until a terrible fall ended with its nice capability of taking good pictures, during the 25C3 in Berlin.

Yes, it’s me again with this DSA-1571 exploitation issue. The discovery, explanation and exploitation of the bug is now part of my final coursework for my postgraduate degree career. So, yes… sorry.

Some weeks ago I started suspecting about the attack to PFS in SSL with EDH. The key point is: the key space is dependent of the PRNG state. The bug affects the initialization of the PRNG, but the random string has not a pattern by it self. If you ask for many random numbers to the PRNG, you gonna get numbers that differ among them, since they are the output of a hash function of them self. So each random number depends on, besides the PID, the state of the PRNG pool in the moment (in other words, amount of bytes that you already pull from the PRNG pool before)

The explained attack was based in a fixed list of private exponents (which are selected randomly during the DHE handshake), presupposing that all the application call RAND_bytes() the same number of times before get it. To make the list of exponent I ran the openssl s_client with all the possible PIDs, hoping that all the applications behaves the same way.

After more tests I notice that that was an overgeneralization. The proof is in the pudding: wget and cURL, two simple CLI file retrievers, gets different exponent between them, even running with the same PID.

I was working on this when I accidentally found a really nice Eric Rescorla’s post which is deeply related with this. The post goes further and analyzes the interaction between how Apache forks off and how it generates SSL handshakes.

So, I made lists of secret exponents for wget, curl, openssl s_client and openssl s_server with a modification version of libssl (appling this messy patch) and running scripts like this:

for i in $(seq $((2**15)));
do
  export MAGICPID=$i;
  LD_LIBRARY_PATH="openssl.broken/" LD_PRELOAD="./getpid.so" \
     wget --no-check-certificate https://localhost/ -q  -O /dev/null ;
  echo $i ;
done

As you can see, I used the HD Moore’s GetPID faker shared library and a normal local Apache with mod_ssl. The broken libssl (which is in .openssl.broken/) store up in /tmp/data.key a csv with command name, PID and all the DH components (g, x, y and p).

But this way is farly unconfortable for others SSL deamon servers. Have you got any better idea?

Maybe the LHC is robing the planet of angular momentum. Maybe having played with quantum gravity has unpredictable consequences. Who cares the reason, it’s my dream becoming true.

And you, haven’t got any plans for the extra day in October yet? Luckily it’s weekend.

Digamos que este post solo tiene sentido si es visto desde mi antiguo gestor de blog. De todas formas decidí portarlo aquí por razones históricas.

Desde ya hace tiempo que tenía intensiones de irme de LiveJournal. No es que funcione mal. Es que simplemente tiene cosas que no me cuadran. Me la paso adaptándome a lo que puede darme (como el caso de hack para el bloguear en planet.debian.org) y tiene limitaciones de diseño. La publicidad que empezó a surgir a la derecha de la pantalla es la gota que derramó el vaso. No es solo antiestética, sino que si decido tener publicidad es porque espero cobrar por ella.

Dado que RaqLink puede proveerme un hosting gratuito y que otros amigos han ofrecido espacio y ancho de banda, decidí mudarme y tener mi propio Blog que dependa de mi mismo.

Así fue como me decidí por WordPress. Es lindo, sencillo y flexible. Por otro lado, dudo de su seguridad. Y este último punto no es menor. Veremos que tal anda durante los próximos meses. Si da mucho problema… volará por otra opción. Escucho opciones.

Una cosa es segura. No más LiveJournal. Este blog (es decir, lbello.livejournal.com) deja de existir como tal. Puedes acceder al nuevo en www.lucianobello.com.ar. Todos los post antiguos está migrados. Incluso los comentarios. En la pasada se han perdido los tags y el threading de los comentarios. Los primeros irán emergiendo con el correr del tiempo y de mi ratos libros. El segundo está definitivamente perdido. Aunque los nuevos comentarios si pueden anidarse, los viejos han quedado planos.

Finally, this alternative speaker became an speaker, nothing more. Maxi and I will be given a lecture during Black Hat, as you can see here.

Just think about being in the same rostrum than Fyodor makes me feel so small…

( I love acronyms :-D ) Tal vez quieras leer esto en español.

At this point, all of you should know and see how the H D Moore’s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).

Introduction to EDH

Let’s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

• The server selects a random prime p and a generator g of the field Z*_p (Let’s ignore the mathematical properties of these values). So, the components p and g are public.

• The server picks a secret random number X_s and calculates Y_s=g^X_s mod p. Y_s is public and is sent to the client (just like p and g).
• The client does something similar, selecting a secret random number X_c and calculating Y_c=g^X_c mod p too. The client makes Y_c public by sending it to the server.
• The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=Y_s^X_cmod p and for the server s=Y_c^X_smod p.
• With this shared secret the parties can encrypt all the following messages in a secure way.
• In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.

The “exploit”

If an eavesdropper can explore the complete private key space (the all possible numbers for X_c or X_s), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That’s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

• The patch for Wireshark 1.0.2 can be downloaded from here.

• Debian packages with the patch applied can be found here.
• This is a list of all 2¹⁵ possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
• An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD=‘getpid.so’ ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.

Issues that can be improved

We (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark’s bugzilla:

• When the packets are out-of-order the decipher with stop itself.

• The brute force attack should run in a background process (and with a progres bar)
• Check the length of the keys before trying to brute force them.
• The patch also implements the display of public DH parameters in the packet tree. It’s incomplete.

Credits

Paolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

And maybe this petition would sound you like an abuse of this situation. And maybe you are right.

The fact is, I need an sponsor to travel to Defcon16, in Las Vegas, the next August. I need a flight ticket, 3 or 4 nights in a hotel and 2 meals per day.

I’ve been accepted to explain the Debian/OpenSSL problem and I’m dying to be there. If you work for a company which is looking for a nice way to say “thank you”, please consider this option :)

Contact me at luciano <alt+64> debian.org for more details. Thanks.

update (13 minutes later): I just received confirmation from the Black Hat organization to be an alternative speaker there too! So I will need to fund 5 extra nights… :D

update (Jun. 6th): I already have a sponsor! :D. Thanks a lot to all the contributors/mentors/impeller ppl, especially to physical people for the monetary-small-but-emotionally-significant colaborations: Juan Tula and Alejandra García.

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL’s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It’s hard, but it’s necessary.