Brainware Crash Report

Debian OpenSSL bug

2008-05-18T00:44:00.000-07:00

A huge security hole has been discovered in the Debian OpenSSL and OpenSSH packages:
http://it.slashdot.org/article.pl?sid=08/05/13/1533212
Introduction:
Modern-day cryptography relies on computer-generated, random encryption keys. Random keys are used everywhere - from generation of public/private key pairs, signatures and certificates, all way to basic login onto ssl or ssh server, when you enter password - the Diffie-Hellman key exchange is used to negotiate random encryption key.

It is absolutely crucial that the "random numbers" are hard for attacker to guess. Normally, the keys have insanely high number of possibilities, in the billion billion billion billion billion billion possibilities range. But in Debian Linux (and anything Debian-based, e.g. Ubuntu), for almost *2 years*, it had only 32 thousands possible keys (per every architecture). That could be cracked with WW2-era hardware. Enigma machine was more secure than that!

Now, how and why this happened?

Theres original conversation from when the bug was introduced:
http://marc.info/?l=openssl-dev&m=114651085826293&w=2

There was 2 "MD_Update(&m,buf,j);" lines commented out in 2 functions.

static void ssleay_rand_add(const void *buf, int num, double add)
...
MD_Update(&m,buf,j);
...
(which was the only place in the function that made use of "buf")

and

static int ssleay_rand_bytes(unsigned char *buf, int num)
....
#ifndef PURIFY
MD_Update(&m,buf,j); /* purify complains */
#endif
...

The first function, ssleay_rand_add, adds the input data into the "entropy pool". It is used to add bytes from /dev/[u]random and from various events such as mouse motion etc. The buff parameter is input-only, named "const void *buf" . And this MD_Update is the only place where it reads from buff. So commenting out almost entirely disabled the random number genration.

Second function outputs random numbers into buff (its output parameter); nonetheless, it does read content of the buff to enhance randomness. This is not very good thing to do as it confuses some debuggers.
Hence, there is
#ifndef PURIFY
#endif
block around it, allowing you to use -DPURIFY if you want to improve debugging.

Rather than using common sense, "dont mess with other people's code unless you have to" and using -DPURIFY , which is *the official way of dealing with problem* , Kurt comments out that line. And more, he searches for anything similar and comments the other one out too!

He does take the time to ask the SSL team about the change, just posting the line numbers, no context, no even function declarations. Just an overly long blabla text. What kind of manners is that? Developer is supposed to open files, go to those lines, and look? Note that he's *not* submitting proper patch asking for it to be accepted. Keep in mind that Debian is just one distribution out of many.
He doesnt take the time to look at the code (and is not a competent programmer); the const in "const void *buf" means that buf is input, "read-only" parameter, and is obviously here for something useful.

Now the fix. It is still very moronic: rather than simply removing the breaking patch and sticking to official openssl without custom changes (maybe using -DPURIFY when compiling) , only the first line is uncommented. WTF. The original break was moronic, the solution was moronic too.

This is just tip of big iceberg. Linux distro maintainers (read: largely, incompetent programmers and n00bs, wannabe elite hackers) do "fixes" in the code that they absolutely do not understand. Being n00bs, they don't properly submit patches to real developers (not that it would help for those "fixes" which are crap and are not accepted anyway). It also highlights the possibility of planting backdoors into open source code. When simple comment out like this remains undetected for almost 2 years, a cleverly hidden backdoor may remain undetected forever.

The advice is: If security is important to you, *stay away from distro packages*. The OpenSSL package in your distro is not OpenSSL. It is a fork of OpenSSL. Which may contain ANY sort of shit, all way from idiocy to clever, deliberate backdoors.

Also, general comment on OpenSSL code. It is over-complicated, and code quality looks bad. There is a lot of room for hidden backdoors.

Skype times again

2008-04-16T10:24:00.000-07:00

(follow up on previous post about skype.)

So, i'm getting asked to explain the calculations for skype timer overflow date.
Note: to understand this post, you need to know some mathematics, especially different bases numbers (such as binary (base 2) and hexadecimal (base 16))

There you can find sample data (in hex) from skype log: http://dmytry.pandromeda.com/texts/skype_chatlogs_friday_13.html

To get nice data to analyze, you can send messages to echo123 (aka "Echo / Sound Test Service") with text ` (backward quote, the key left of 1).
If you're lucky, echo123 will reply to you with something like this:
Echo / Sound Test Service : yournickname 2008.04.12 12:42:22
so that in chatmsg256.dbb you have both skype's binary timestamp, and human readable time in message text. (Note, this time is in GMT+1 now, not GMT, dunno why.)

The binary timestamp in that sample message is 0x85 0xA4 0x82 0xC0 . I located timestamp by comparing multiple messages in the log and looking what is different between those.

As you can see all bytes are bigger than 0x80 . That means first bits of those bytes are 1. As i found out (again, by looking at many messages in the log), them are always set to 1, for all times, and whole thing increments as if those bits are not present here at all. So, these bits have to be ignored to get the number that skype actually stores there. In whole number, we get only 28 bits (4 bytes, each has one bit that is ignored and 7 data bits. Total 28 data bits).

The skype's time number can be obtained as
(0x85-0x80) + (0xA4-0x80)*2⁷ + (0x82-0x80)*2¹⁴+ (0xC0-0x80)*2²¹ = 134 255 109
The subtraction of 0x80 is to compensate for those first bits being always set to 1 . Multiplications by power of two are to get those 4x7 bits together into single 28 bit number.

Sample message, for which we got the skype's timestamp number, was sent on 2008.04.12 12:42:22 as we can see in the message itself (the message was automated reply from echo123 with current time), and GMT+1 , not GMT . so thats 11:42:22 GMT

The time overflow date is
T = [2008.04.12 11:42:22] - 134255109 seconds + 2²⁸ seconds
where first part is the date of message, second part is skype's timestamp value (we subtract timestamp value from date to find from which date the skype counts seconds), and 2²⁸-1 is maximal number that can be storen in 28 bits, next number causing overflow.

It is bit difficult to add and subtract large numers of seconds from datetimes. As far as i know, Google calculator does not support datetime values.
Fortunately, theres tools on the web which can do that. You can simply convert date to standard unix timestamp (seconds elapsed since 1970), then add your seconds, then convert back to year/month/day etc
Using
http://www.epochconverter.com/
to convert [2008.04.12 12:42:22] we get Epoch timestamp: 1208000542
Using google calculator again, we get
1208000542 - 134255109 + 2^28 = 1342180889
and last step, converting it to human readable date using http://www.epochconverter.com/
we get Fri, 13 Jul 2012 12:01:29 GMT

I think it came out 1 and half minute off because skype used one clocks to set timestamp, and another clocks were used by echo123 when replying; also echo123 replies with large delay. In the converter program, i use 12:00:00 GMT exactly.

notes:
numbers like 0x1ABCD2 and so on are in hexadecimal, i.e. base-16 notation. 0x is standard prefix for hexadecimal numbers, used to tell those apart from decimal. the rest is number itself. For digits past 9, alphabet is used. A=10 , B=11 , C=12 and so on.

The echo123 bot does not always reply, you can check without echo123 but then you need to yourself get date and time as skype shows them to you.

Friday, 13th July 2012, 12:00 GMT - the apocalypse is about 5 months closer than mayans believed

2008-04-13T12:10:00.001-07:00

Maya were possibly the first to have their calendar end in 2012 , but sure they weren't last.
Today i found that popular internet telephony program Skype followed the trend.
On Friday, 13th July 2012, 12:00 GMT , the skype's time counter gonna overflow ! Or at least its gonna enter the New Byte Epoch, or how skype developers call their equivalent of mayan "Galactic Day".
(Unfortunately, skype seem to use server time to store timestamps, rather than client computer's own clock time. I tried setting time to past 13th July 2012, 12:00 GMT, but the times in the log were correct times of today. We'll either have to wait till 2012 to see what happens, or reverse engineer skype's binaries, or set up some fake server, or something like that.)
More on this:

There wasnt any good tools avaliable for converting skype logs (which are binary) to text, and i needed to convert a few logs, so i had to write tool myself.

On my website, you can get more information about skype chat log format.
Development of tool:
Extracting sender and messages themselves from logs was easy, the harder part was decoding message timestamps.
I found that timestamp is stored in 4 bytes, and all bytes have their first (sign) bit set, which looked quite weird. Ignoring first bits and interpreting it as 28-bit number, i got some number that looked like number of seconds since some date.
Then, comparing time to skype timestamp, i found that e.g. 2008-04-12 17:33:43 corresponds to skype timestamp 134276281
From now on finding times was easy job :-)
Standard unix epoch time (seconds since 1970) for [2008-04-12 17:33:43] is 1208021623, and the difference between standard and skype's timestamps is about 1073745342 . In other words, skype's timestamp is number of seconds since approximately Sat 10 Jan 2004 14:35:42 (the difference converted to human readable format).
That date and time looks like pretty strange choice of time to count seconds from. Not a midnight or midday...
I got curious, when does it overflow? As quick calculation showed, it overflows on friday 13th july 2012 , 12:00 GMT (my time was few seconds off, but thats allright). Which is obviously by design.
So, i thought, wow, thats first class blogging material! So there we go :)

This also explained weird thing about first bits of all bytes being set. If you interpret the bytes as signed 8 bit numbers, they're all negative. So if you add them like first byte + second byte*2⁷ + third byte*2¹⁴+fourth byte*2²¹, you get negative number which is number of seconds to friday 13th july 2012 , 12:00 GMT

This also means that skype timestamps will probably continue working after friday 13th july 2012 , 12:00 GMT , just they wont have first bits set anymore.

For geek readers, in skype (version 2.0.0.13 for linux, at least) the timestamps in skype .dbb files are fairy easy to spot in hex viewer. Them are placed between list of people in the "chatroom", and the sender's skype name. The timestamp is prefixed with E5 03 . It is 4(?) bytes long. The fifth byte after those four is always equal to 4 so i dont know if fifth is part of timestamp and timestamp is actually 5 bytes long, or fifth byte is just some sort of delimeter or control character. It is followed by 03 , like all other skype's delimiters, so i think it probably is just a delimiter.

p.s. i used http://www.epochconverter.com/ to convert seconds to time and back during testing.

p.p.s if you found this interesting, visit my website on http://dmytry.pandromeda.com

teh first post to my blog

2007-06-13T06:26:00.000-07:00

Firstly some info about myself and creation of this blog: I had some difficult project related to my volumetrics software, and quite severely broke down. At first it was quite good - i feelt unification with all living things on the planet. Undestood Everything At Once. Travelled from one world to other in comfort of my house. Also on less bright side, died thousands painful deaths, in dream. I didn't take any drugs or "energy drinks", mind you. Not even caffeine. Now i'm mostly recovered and working again.

There's some observation of factors which might have caused this:
1: listening to music while coding, coding in sort of trance. 2: sleeping less did make it easier for me to concentrate on work, so i sleept around 6 hours. 3: working alone, me and my computer and my internet connection. 4: i practiced turns for dancing, and possibly got something in my head damaged, i recall i got headaches from it. 5: sudden termination of project. While i were working, it was allright coz i were too busy to get crazy :-) .

Speaking of headaches, i recall i got headaches in childhood for first time when i was 8..10 years old and some guy did demonstrate some self defence trick on me, smashing my head hard into ground. I didn't pass out but had so bad headache afterwards that it made me wish to die. And next day he did it again (we were supposed to play football)). Hmmm. I had idea to do CT scan of my head, but psychiatr talked me out of this idea.

Current passtime: studying math over again. Writing to blog.

Nuclear Laptops.

2007-10-05T06:56:00.000-07:00

I use stumbleupon and lately for 5 times i've been stumbling onto webpages about "laptop batteries that lasts 30 years". This bullshit is getting annoying. There's no way these batteries going to be public.

Several quotes from article:
"We have a non-thermal reactions so there is also no risk of over-heating"
Non-thermal reaction. Yeach.
Laptop consumes over 50W of power. Quick search shows that maximal possible electrical conversion efficiency for betavoitaics is around 25% which means there needs to be 200W of total power, 25% of which, that is 50W is converted to electricity (so in laptop you have 150W coming as heat directly from the battery, and 50W of heat coming from electronics). Surely such laptops are going to be very hot product.

"when the battery runs out of power it is non-toxic"
Radioactive decay doesn't work like emptying bathtub. After time of half-life, there's half of radioactive material, after two times of halflife there is quarter (and so on). Suppose battery is 2x more powerful than what your laptop needs. It means that when battery no longer could power your laptop, there is still a half of radioactive material remaining in the battery (actually battery is going to die earlier than that because of degradation of semiconductors due to radiation, but i digress).
Now, on the toxicity. Beta particles don't travel much distance in materials The radioactive material could be made into some mostly insoluble form to prevent it from contaminating environment and being ingested. I'm not sure about how insoluble it could be made. All i know is, it takes very little radioactive material to poison a human, comparing to amounts of material producing such power output levels.

Dreams

2007-10-03T05:45:00.000-07:00

A day ago i seen space shuttle takeoff in a dream. That was quite a sight. This morning i had lucid dream and did fly around something resembling my city, that was a lot of fun. It was tad different from real city though.
Dreams always fascinated me... quite accurate virtual reality produced by brain itself, for unknown purproses. Some dreams are like movies, sort of like watching the plot unfold, in some you feel "being there", and some are lucid (where you realize it is a dream and have some control). Then there is false awakenings, when you dream that you wake up.
One thing i want to do if i ever get a computer in lucid dream is try to see if i can program it to do something interesting. I had dreams with computer and internet, doing usual stuff like checking email or messaging, or even looking up something in google, but never programmed a computer in dream (or played computer game).

In other dream unrelated news, i have a paid job now, programming some graphics tools. No images there, sorry, the work is covered by NDA.

More work on volcano

2007-07-20T11:09:00.000-07:00

Working on volcano now. A test render. Still a lot of work to do to get it anywhere near photorealism

Volcano

2007-07-14T04:19:00.000-07:00

I'm working on procedural volcano (made with volumetrics). I'm coding the procedural in C++ because user interface is not ready yet for this kind of tasks. There's test render. I'm using erosion fractal on terrain, however it is fairy difficult to adjust settings for nice erosion on the volcano.
Todo: smoke cloud, terrain texture, more tweaks of volcano shape.

A test render using curve.

2007-07-10T09:37:00.000-07:00

A test render using curve editor. By the way, i implemented undo and redo in curve editor.

Curve editor works.

2007-07-05T02:00:00.001-07:00

I have implemented basic spline curve editor. User interface is very simple for now: doubleclick adds spline control point, single click selects, delete key deletes, control points can be dragged. Slope lines can be dragged too to set slope at control point. Legend: curve is red, control points are blue, selected control point is green, slope line is white.
Todo: undo and redo functionality.

More programming.

2007-06-30T07:29:00.000-07:00

Still programming curve editor UI. I might take a break from it and code something for nice image. No other news except that i begin to lose interest in blogging, which is noticeable as my blog entries get shorter and shorter.

Reading Master and Margarita

2007-06-27T03:35:00.000-07:00

I'm re-reading Master and Margarita now. I did read it before but forgot everything so i have the pleasure to read it again like for first time :)
Programming: did some work on curve editor in standalone volumetrics UI.

Got stuck at UI programming.

2007-06-22T06:57:00.000-07:00

Got stuck not sure how to go about implementing the curve editor (cubic hermite spline editor that is). No other news. I'm feeling kind of depressed now.

A test render.

2007-06-21T03:03:00.000-07:00

Screenshot from the editor, along with the test render. Concept of user interface: the scene is represented as tree of "operators", operator tree is displayed on the left, operator properties on the right. Operators have channels for connections between them; the Perlin noise operator's evaluation position and result are connected to Monofractal, which in turn is connected to clouds. There's some usability problem: it's possible to get noise connected directly to clouds, bypassing the Monofractal. I'm unsure how to go about this usability problem.
The most important lacking thing now is curve editor, it is necessary for getting clouds disappear at top and bottom of layer rather than get clipped by layer bounds.

Some technical blabla

2007-06-20T12:36:00.000-07:00

This post is technical and is more of a note for myself rather than for audience
(though that applies to most of my posts)

I resolved that database problem.
How and what happened: During loading, there's some connections binding going on. When loading Monofractal it would first load PerlinNoise, and create ".inputs" folder in monofractal for binding of monofractal's inputs to the outputs of PerlinNoise. Then it would try loading saved .inputs folder, and fail to add it into database because .inputs folder already existed.

Implemented monofractal, photographed some bug

2007-06-20T06:30:00.000-07:00

In implementation of monofractal I had some "i instead of j" mistake that did take quite some time to find because it was array index and in result program were writing outside of bounds of array, screwing up the heap (which makes program crash somewhere further along).
Test images i made so far sux so i won't upload them ;-).

Also i've discovered some strange problem in my database thing that works behind the scenes in my framework/user interface. Somehow saved files are not always loaded properly. It is going to take some time to sort out.

In other news, on 17th i found a fairy big, mean looking dead bug laying on the street. To be specific, it was exosceleton of some bloodsucking fly whose name i don't know. I photographed it today:Nice, eh?

Implemented Perlin Noise.

2007-06-19T02:59:00.000-07:00

A test render, and user interface screenshot for that test render.
As you can see user interface is pretty basic. However it has undo and redo and parameter descriptions; also, there's whole "plugin compiler" thing behind the scenes, binding editable parameters to the internals, and binding the internal connections. In this example, the result of perlin noise is bound to v_density parameter of "Clouds" (so that the density of cloud is set by perlin noise), and perlin noise's Evaluation Pos. is bound to cloud's EvaluationPosition channel (so that the perlin noise is evaluated at position where "Clouds" ask it to be evaluated). "Clouds" themself are bound to Volumetrics, the core renderer.

For now, user interface doesn't have working "render" buttons or the like; scene file is saved and then rendered with CLI version. It gonna take lot of time until user interface becomes actually usable by normal users.

2007-06-18T02:51:00.000-07:00

Another test image, using same sine wave function. Working while listing to Abba now (Rammstein is kind of too heavy). That was an important first step - it verifies that my procedural editor framework is allright. Still, a lot work to do to make actually usable user interface.

Some more programming of user interface

2007-06-18T00:54:00.000-07:00

An image made from scene constructed using said user interface for volumetrics. I'm using sin(ax)*sin(ay)*sin(az) function for cloud density, camera is somewhere inside cloudscape.

Programming user interface for volumetrics

2007-06-17T03:20:00.000-07:00

I'm working on user interface for volumetrics render engine, while listening to Rammstein. There's yesterday's screenshot from overal look of the user interface. Let's hope it wont crash my brain again. I had discovered that my code for user interface and overall framework is much more advanced and sophisticated than what i remember.

Some idea

2007-06-15T05:45:00.000-07:00

When i have time i'm gonna dissolve in dirty water some shugar, salt, aspirine, and other water soluble crystals, and put a drop of it on microscope slide, then let it dry, and take a look through microscope... i will try to photo it with my cheap digicam. Should look cool.

A render

2007-06-14T07:40:00.000-07:00

Some render completed. Nothing groundbreaking here, some nice cloudscape and some almost invisible terrain (whoops). I'm actually wanting to make erosion fractal based mountains with some nice clouds. Need to get good ambient lighting on terrain, need to raise terrain up to the cloud height, etc, etc. I think i will have to code some limited global illumination for terrain, gonna think about it some more.

Blogosaur Pseudosapiens

2007-06-14T01:51:00.000-07:00

A page from notebook, where i've been doing integration by parts (out of boredom). Firstly, it should be (ln x)^3 dx , not ln x^3 dx .
I didn't have enough persistence to do other one with square root (+3 part scared me off, not sure why), and drew a Blogosaur Pseudosapiens instead.
Then i started some render, and wrote this post of blog.
Mood: happy.