Haiti

January 14th, 2010

I turned on my television to see a city razed, a gruesome tapestry of survivors and corpses. A girl, buried under the rubble, was screaming for help; a group of men, after hours, managed to free her from the broken concrete. The reporter asked her if she had been scared, and, unconquerable, she told the camera “her heart never skipped a beat.” Many others felt no more, while those they left behind felt all too much.

Mother nature has no wrath, no anger, no hatred. She feels nothing, she is unadorned indifference. And, this makes her brute violence all the more terrifying. As Thomas Hardy put it,

If but some vengeful god would call to me
From up the sky, and laugh: “Thou suffering thing,
Know that thy sorrow is my ecstasy,
That thy love’s loss is my hate’s profiting!”
Then would I bear, and clench myself, and die,
Steeled by the sense of ire unmerited;
Half-eased, too, that a Powerfuller than I
Had willed and meted me the tears I shed.

But not so. How arrives it joy lies slain,
And why unblooms the best hope ever sown?
-Crass Casualty obstructs the sun and rain,
And dicing Time for gladness casts a moan….
These purblind Doomsters had as readily strown
Blisses about my pilgrimage as pain.

Yet, it is this very indifference and upheaval that burned into us the passion that fires our spirit and ingenuity. We have forged ahead thus far, and we will not go quietly into the night. And, when we see our neighbors shaken, we offer a hand to steady them. Cold indifference, be damned.

Quickies: TLS reneg, Karmic, beauty, suggest, TC

November 12th, 2009

By now, everyone has heard of the TLS renegotiation vulnerability,

Transport Layer Security (TLS, RFC 5246 and previous, including SSL v3 and previous) is subject to a number of serious man-in-the-middle (MITM) attacks related to renegotiation. In general, these problems allow an MITM to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream, leading to a variety of abuse possibilities. In particular, practical attacks against HTTPS client certificate authentication have been demonstrated against recent versions of both Microsoft IIS and Apache httpd on a variety of platforms and in conjunction with a variety of client applications. Cases not involving client certificates have been demonstrated as well. Although this research has focused on the implications specifically for HTTP as the application protocol, the research is ongoing and many of these attacks are expected to generalize well to other protocols layered on TLS.

A nice write-up of the issue can be found here,

Marsh Ray has published a new attack on the TLS renegotiation logic. The high level impact of the attack is that an attacker can arrange to inject traffic into a legitimate client-server exchange such that the TLS server will accept it as if it came from the client. This may allow the attacker to execute operations on the server using the client’s credentials (e.g., order a pizza as the client). However, the attacker does not (generally) get to see the response. Obviously this isn’t good, but it’s not the end of the world. More details below.

As for the response of a popular SSL/TLS implementation, the OpenSSL security advisory can be found here,

The workaround in 0.9.8l simply bans all renegotiation. Because of the
nature of the attack, this is only an effective defence when deployed
on servers. Upgraded clients will still be vulnerable.

A TLS extension has been defined which will cryptographically bind the
session before renegotiation to the session after. We are working on
incorporating this into 0.9.8m, which will also incorporate a number
of other security and bug fixes.

Oh, and about Tor,

The Tor protocol isn’t vulnerable here because 1) it doesn’t allow data to be sent before the renegotiation step, and 2) it doesn’t treat a renegotiation as authenticating previously exchanged data (because there isn’t any).

-

A couple of minor notes when upgrading Ubuntu Jaunty (9.04) to Karmic (9.10)…

Karmic no longer uses event.d.

The version of upstart included in Ubuntu 9.10 no longer uses the configuration files in the /etc/event.d directory, looking to /etc/init instead. No automatic migration of changes to /etc/event.d is possible. If you have modified any settings in this directory, you will need to reapply them to /etc/init in the new configuration format by hand.

I found this page to provide useful addition information.

This specification contains the documentation for the Upstart packaging and upgrade policy.

For example, for the purposes of djbdns, this meant that the “/etc/event.d/svscan” configuration had to be converted to “/etc/init/svscan.conf”. I ended up using the following, which is slightly different than what the Ubuntu djbdns package installs (bullet point 8 of this post is relevant).

# svscan - daemontools -- http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12
#
# This service starts daemontools from the point the system is
# started until it is shut down again.

start on runlevel [2345]
stop on runlevel [!2345]

respawn
exec /usr/bin/svscanboot

And, rsyslog is now in use,

The sysklogd package has been replaced with rsyslog. Configurations in /etc/syslog.conf will be automatically converted to /etc/rsyslog.d/50-default. If you modified the log rotation settings in /etc/cron.daily/sysklogd or /etc/cron.weekly/sysklogd, you will need to change the new configurations in /etc/logrotate.d/rsyslog. Also note that the prior rotation configurations used .0 as the first rotated file extension, and now via logrotate it will be .1.

I played around a little with logging in Ubuntu 8.10 in this post (bullet point 7).

(On a side note, if you are doing more than just simple basics with syslog, it may be time to consider replacements like rsyslog and syslog-ng.)

-

Didn’t I mention beauty and elections at some point? Yep,

Perhaps a just as simple and maybe better way to pick who will be elected president than answering “who is taller?” is to answer this more general question – who best looks the part? (A little lamination goes a long way. ;) ) And, of course, a consensus answer gives better results than each individual answer here.

Well, this paper fits right in with that post.

Are beautiful politicians more likely to be elected? To test this, we use evidence from Australia, a country in which voting is compulsory, and in which voters are given ‘How to Vote’ cards depicting photos of the major party candidates as they arrive to vote. Using raters chosen to be representative of the electorate, we assess the beauty of political candidates from major political parties, and then estimate the effect of beauty on voteshare for candidates in the 2004 federal election. Beautiful candidates are indeed more likely to be elected, with a one standard deviation increase in beauty associated with a 1½ – 2 percentage point increase in voteshare. Our results are robust to several specification checks: adding party fixed effects, dropping well-known politicians, using a non-Australian beauty rater, omitting candidates of non-Anglo Saxon appearance, controlling for age, and analyzing the ‘beauty gap’ between candidates running in the same electorate. The marginal effect of beauty is larger for male candidates than for female candidates, and appears to be approximately linear. Consistent with the theory that returns to beauty reflect discrimination, we find suggestive evidence that beauty matters more in electorates with a higher share of apathetic voters.

-

This made me laugh.

[...]But I was most impressed with this anonymous bit of genius dug up by Digg, which uses Google for some armchair sociolinguistic analysis. The graphic compares “less intelligent” queries with “more intelligent” queries, such as “how 2″ with “how might one:”

-

Lastly, TrueCrypt 6.3 has been with the following new features.

Full support for Windows 7.

Full support for Mac OS X 10.6 Snow Leopard.

The ability to configure selected volumes as ’system favorite volumes’. [...]

Oh, and I should mention… So, we had hotplug and cold boot. And, of course, when your system is up and running and transparently encrypting/decrypting data, a stock exploit of, say, the OS could easily mean game over. Now, people are using bootkit functionality against TrueCrypt.

The provided implementation is extremely simple. It first reads the first 63 sectors of the primary disk (/dev/sda) and checks (looking at the first sector) if the code there looks like a valid TrueCrypt loader. If it does, the rest of the code is unpacked (using gzip) and hooked. Evil Maid hooks the TC’s function that asks user for the passphrase, so that the hook records whatever passphrase is provided to this function. We also take care about adjusting some fields in the MBR, like the boot loader size and its checksum. After the hooking is done, the loader is packed again and written back to the disk.

While gaining physical access to a system and tampering with the hardware or popping on a malicious bootloader or what have you, and then the victim using that compromised system, which proceeds to, say, record the TrueCrypt password for the attacker, is outside the protections of the basic TrueCrypt FDE scenario, seeing bootkits demonstrating their capabilities against TrueCrypt and illustrating just what protections tools like TrueCrypt do and do not provide is quite cool. (And, with that horrific sentence, this post draws to its close.)

Number

September 3rd, 2009

Like Whitman’s spider, here we cast a filament between a few reads, prompted by “Number”.

-

Somewhat in keeping with recent posts, I found Tobias Dantzig’s “Number” (fourth edition – 1953) an interesting tale of the evolution of the number concept that calls attention to things we so completely take for granted today, such as positional numeration (“The struggle between the Abacists, who defended old traditions, and the Algorists, who advocated the reform, lasted from the eleventh century to the fifteenth century and went through all the usual stages of obscurantism and reaction.”). Much of the book is fascinating, such as the following excerpts of possible interest to our readers.

(The human computer is quite different from that there laptop,)

The advantages of the base two are economy of symbols and tremendous simplicity in operations. It must be remembered that every system requires that tables of addition and multiplication be committed to memory. For the binary system these reduce to 1 + 1 = 10 and 1 X 1 = 1; whereas for the decimal, each table has 100 entries. Yet this advantage is more than offset by lack of compactness: thus the decimal number 4096 = 2^12 would be expressed in the binary system by 1,000,000,000,000.

(On the term cipher and the spread of the concept of zero,)

[...]In the English language the word cifra has become cipher and has retained its original meaning of zero.

The attitude of the common people toward this new numeration is reflected in the fact that soon after its introduction into Europe, the word cifra was used as a secret sign; but this connotation was altogether lost in the succeeding centuries. The verb decipher remains as a monument of these early days.

(Think infinite and calculus,)

The conflict between discrete and continuous is not a mere product of school dialectics: it may be traced to the very origin of thought, for it is but the reflection of the ever present discord between this conception of time as a stream and the discontinuous character of experience. For, in the ultimate analysis, our number concept rests on counting, i.e., on enumerating the discrete, discontinuous, interrupted, while our time intuition paints all phenomena as flowing. To reduce physical phenomena to number without destroying its streamlike character – such is the Herculean task of the mathematical physicist; and, in a broad sense, geometry too should be viewed as but a branch of physics.

(And here we take a trip…)

The latter brings to mind Virginia Woolf’s “Mrs. Dalloway” (1925),

All the same that one day should follow another; Wednesday, Thursday, Friday, Saturday; that one should wake up in the morning; see the sky; walk in the park; meet Hugh Whitbread; then suddenly in came Peter; then these roses; it was enough. After that, how unbelievable death was! – that it must end; and no one in the whole world would know how she had loved it all; how, every instant …

Of course, I note the following congruence between “Spent” and “Mrs. Dalloway”…

From Geoffrey Miller’s “Spent” (2009),

[...]Almost every dog breed has some idiosyncratic high-maintenance feature that makes it an effective means for displaying conscientiousness, and all require regular feeding, watering, walking, vet care, and diligent physical restraint by leashes and fences. Hence the social and sexual popularity of single people who can be seen walking dogs that are conspicuously well fed, well-groomed, well trained, nonneurotic, and nondead.[...]

From Woolf’s “Mrs. Dalloway”,

Then Clarrisa, still with an air of being offended with them all, got up, made some excuse, and went off, alone. As she opened the door, in came that great shaggy dog which ran after sheep. She flung herself upon him, went into raptures. It was as if she said to Peter – it was all aimed at him, he knew – “I know you thought me absurd about that woman just now; but see how extraordinarily sympathetic I am; see how I love my Rob!”

Now, Elena Ferrante’s “Days of Abandonment” is stylistically reminiscent of Woolf’s “Mrs. Dalloway”. As Septimus (and Clarissa) verge on dissolution in “Mrs. Dalloway,” Olga in “Days of Abandonment” gives us a view into the mind of someone on the brink of insanity.

From “Days of Abandonment” (2005 english translation),

[...]I tried again to open the door. I couldn’t do it. I leaned over, I examined the key closely. Finding the imprint of the old gestures was a mistake. I had to disengage them. Under the stupefied gaze of Ilaria, I brought my mouth to the key, tasted it with my lips, smelled the odor of plastic and metal. Then I grabbed it solidly between my teeth and tried to make it turn. I did it with a sudden jerk, as if I wished to surprise the object, impose a new statute, a different dispensation. Now we’ll see who wins, I thought, while a pasty, salty taste invaded my mouth. But I produced no effect, except the impression that, because the rotating movement of my teeth on the key wasn’t working, it was finding an outlet in my face, tearing it like a can opener, and my teeth were moving, were being unhinged from the foundation of my face, taking with them the nasal septum, an eye brow, an eye, and revealing the viscid interior of my head.

(Anon, through sane eyes, we find “The key turned in the lock simply.”)

Notable is the portrayal of insanity as a representation of the world constructed by a person’s mind that skews too far from the necessities of the reality around them, a representation incoherently blurred by memories and imaginations and hallucinations, a representation that makes their ability to survive, reproduce, function out there in the world quite difficult. (One could think of the economic bubble that recently occurred as insanity.)

Which somehow made me think, if people’s representations of the world could be assigned some sort of numerical metric and be plotted over the number of people with that representation, should we visualize a bell curve of a normal distribution? Ah, but, bell curves bring to mind means. Aristotle spoke of means; to that end, from “The Ethics of Aristotle” (1953 English translation),

In anything continuous and divisible it is possible to take the half, or more than the half, or less than the half. Now these parts may be larger, smaller, and equal either in relation to the thing divided or in relation to us. [...] The man who knows his business avoids both too much and too little. It is the mean he seeks and adopts – not the mean of the thing but the relative mean.

Of course, Aristotle makes me think of Greek philosophers. Coming back to “Number”, Dantzig quotes Philolaus, a Pythagorean, as saying,

All things which can be known have number; for it is not possible that without number anything can be either conceived or known.

Alas for the Pythagoreans, the irrationals revealed by the Pythagorean Theorem! Hippasus drowned! Dancing round the ruler and compass, what was it Eliot said in “The Hollow Men”,

 Between the idea
And the reality
Between the motion
And the act
Falls the Shadow

Moving us toward where we parted, William Blake in “Augeries of Innocence” now pops into mind,

To see a World in a grain of sand,
And Heaven in a wild flower,
Hold Infinity in the palm of your hand,
And Eternity in an hour.

Perhaps, as Wordsworth once wrote, “the world is too much with us”; but then we have these sublime writers, poets, mathematicians! Alas, the act is up; the thread must be caught; summer’s grand finale is at the door. So, we end with the close of Dantzig’s “Number”,

In this, then, modern science differs from its classical predecessor; it has recognized the anthropomorphic origin and nature of human knowledge. Be it determinism or rationality, empiricism or the mathematical method, it has recognized that man is the measure of all things, and that there is no other measure.

It’s turtles all the way down, dear reader, turtles all the way down! ;)

Violent rambling, etc.

August 7th, 2009

Behold! Behold!
What lo?
A ramble! A ramble!
What? No!
‘Tis so! ‘Tis so!

-

I think we often take for granted the hidden knowledge built into our cultures, our institutions, our norms, to the degree that we take the results of these structures, of this genetic code for our society, as just a given. I must say that, when I was younger, the more radical beliefs I held at the time were in part motivated by the accumulated noise, junk, I perceived in those structures about me while ignoring the information also contained therein; now, I have more respect for the hidden knowledge in such systems and the hidden assumptions on those systems and their knowledge.

So, I recently read Girard’s “Violence and the Sacred”. In it, Girard discusses the idea that all society, all culture, even all symbolic thought is the byproduct of what he calls a sacrificial crisis, which entails a cycle of reciprocal violence and violent undifferentiation within a community, that culminates in the elimination of a sacrificial victim, whereby the community unites against one member of the community and, in a generative and bonding moment, releases their violence upon that member, thus expelling their violence from the community. According to Girard, religion enshrines this sacrificial crisis and victim, and ritual allows for the re-enactment of the crisis and victim to expunge the violence within the community. (Girard’s, say, over the top, argument is that this crisis-victim is the foundation of all community and culture, and that trying to understand the crisis-victim is what caused symbolic thought to emerge. Side note – I mention symbolic thought with regards to the financial system in this post.)

Thinking on it, I can see the sacrificial crisis culminating in a sacrificial victim, and the ritualized enactment of such an event, applied within communities in the world in which I live today. As Girard discusses, while sacrificial victims may be selected at random in the midst of a crisis, surrogate victims used during the ritualized replay of the sacrificial crisis are often chosen both because they have ties to the community (and so can be substituted for it) and yet because they are outside it (and so have little potential to inspire reciprocal violence). When I look at, say, news of late, where “obese” people seem to be sacrificed in the war on health care costs, I cannot help but see parallels to the surrogate victim in primitive religious rituals (irrespective of any opinion held on the matter).

There is an interesting misdirection noted by Girard as well, the belief that violence stems from something outside of humankind, such as the gods or the dead. This too it seems is visible today in much rhetoric. People speak as if violence itself stems from a gun or from a video game or from a car, from these sacred and powerful items that are outside the world of people, external objects capable of infecting people with violence when they descend upon a community. (I am ignoring any correlation that may exist between these objects and people’s propensities toward violence.)

Regardless of views, the importance of violence, or rather, the expulsion of violence from, within the community appears to be hugely important to, and completely buried in, the very foundations of society as we know it today, at least in the culture in which I reside. This seem to be so much the case, that we take the end result for granted.

For example, Girard points out the significance of the judicial system in replacing religion, such that the judicial system takes on a higher authority as a impartial and superior body, that metes out revenge, relabeled a transcendent term, justice, upon parties of established guilt in the name of the community. The very sublime nature of the institution makes the act of revenge the judicial system deals out beyond revenge, and so it breaks the potential chain of reciprocal violence.

We often take the incorporation of the judicial institution into our culture for granted, as we assume such institutions and such cultures are a given, natural. But, violence has been with us long before such institutions existed. Nature is violent at times, and it makes sense that we have evolved a potential for violence ourselves; we have survived over the long course of time both in spite of and because of violence. As such and in broader terms, I am beginning to think that taking current culture, current norms, current institutions for granted is quite dangerous.

This idea of the generative and community building aspects of violent unanimity also seems in line with Peter Turchin’s ideas “War and Peace and War” (mentioned in this post, particularly bullet point 2) that a common struggle against, say, a foreign enemy can bring people together, that it builds the capacity for collective action. Great nations are forged in the frontier life, in the world of violent interactions between similar peoples with less similar peoples. In this light, Girard briefly notes wars with foreign nations as an example of unifying violence, in that the foreign nation becomes the sacrificial victim, the embodiment of violence that is outside the community ,and yet a violence that has been brought to the community and must be violently expunged.

Girard notes that change is often feared by primitive communities as a potential trigger of violence, and often there is lots of ritual performed around change to relieve any potential for violent buildups, such as at times of seasonal transitions or the coming of age of a child. In bullet point 2 of the aforementioned post, I noted that “radical change can cause instability” along with a slightly broader discussion of change or adaption in a follow-up post. Additionally, Schoeck notes in Envy that extreme envy and envy avoidance, such as that in exhibited in primitive communities and small towns, can often stifle innovation, creativity, and achievement, all of which have undertones of change. So, combining this with Girard, we can see envy threatens violence, and, violence being contagious, such a threat could wipe out a whole community, which leads us to innovation, creativity, and achievement, as purveyors of change, being punished and avoided.

Now, it is easy to forget walking down the street in NYC just how much everything around us requires this breaking of the chain of reciprocal violence. In the past, when men could easily descend into a tornado of violence and everything else was swept aside by it, the world as we see it now in NYC could not exist. The weak would have to huddle together and perhaps flee the storm, and the strong could tear everything down in a moment of rage.

That is not to say that violence is not still present, but that most people tend towards non-initiation of violence, and the rare initiation of violence tends to end at the time it begins. Self-defense is acceptable at the moment of being attacked, but, after the fact, we rely on law enforcement and the judicial system to catch and punish the aggressor; vigilante-ism and personal revenge are frowned upon and punished, norms that reinforce a breaking of reciprocal violence. (In some communities in NYC and the USA in general, reciprocal violence may still run free, such as gang violence or the eruption of riots; however, those are the exceptions and not the norm.)

Evolution is the way of nature and, as such, ourselves, and I rather enjoy this spiraling progression, much as I like the evolution of what I consider to be my self as I grow older. As noted by Turchin’s “War and Peace and War” or in Michael Flynn’s scifi-esque “Introduction to Cliology” (inspired by Asimov) or even Barrow’s “The Artful Universe”, we live in cycles within cycles, in this chaotic nature, and so we must. But, I maintain a certain sense of caution when unraveling the fabric of our modern world, as pulling at the strings of our norms, cultures, institutions, communities, etc. without properly considering their hidden store of knowledge, and the hidden assumptions one might be making, can have quite profound and completely unintended consequences, for better or worse.

-

I mentioned “the map is not the territory” in this post. How about another? “Correlation is not causation.” This is one of those great insights that we so often fail to see. I have made this mistake at times in this blog.

So, if I had remembered nothing else from Judith Rich Harris’ “The Nurture Assumption”, then the wit, and the clear and concise explanation of “correlation is not causation” that makes the concept easy for me to explain to others, would have made the book worth it. An excerpt of her fictional example to illustrate correlation is not causation,

[...]Our method will be straightforward: we will ask a large number of middle-aged people how much broccoli they consume and then, five years later, check to see how many of them are still alive.[...]

[fictional results showing a statistically significant correlation between eating broccoli and longevity in men but not women]

Our study appears in an epidemiological journal. A newspaper reporter happens to read it. The next day there’s a headline in the paper: EATING BROCCOLI MAKES MEN LIVE LONGER, STUDY SHOWS.

But does it? Does the study show that eating broccoli caused the male subjects to live longer? Men who eat broccoli may also eat a lot of carrots and brussel sprouts. They may eat less meat or less ice cream than broccoli shunners. Perhaps they are more likely to exercise, more likely to buckle their seatbealts, less likely to smoke. Any of these other lifestyle factors, or all of them together, may be responsible for the longer lives of the broccoli eaters. Eating broccoli might even have been shortening our subjects’ lives, but this effect was outweighed by the beneficial effects of all the other things broccoli eaters were doing.

-

The 0.2.1.x branch of Tor has gone to release.

Tor 0.2.1.18 lays the foundations for performance improvements, adds status events to help users diagnose bootstrap problems, adds optional authentication/authorization for hidden services, fixes a variety of potential anonymity problems, and includes a huge pile of other features and bug fixes.

Bravo.

-

Attacks only get better.

In this paper we describe several attacks which can break {\it with practical complexity} variants of AES-256 whose number of rounds are comparable to that of AES-128. One of our attacks uses only two related keys and $2^{39}$ time to recover the complete 256-bit key of a 9-round version of AES-256 (the best previous attack on this variant required 4 related keys and $2^{120}$ time). Another attack can break a 10 round version of AES-256 in $2^{45}$ time, but it uses a stronger type of {\it related subkey attack} (the best previous attack on this variant required 64 related keys and $2^{172}$ time). While neither AES-128 nor AES-256 can be directly broken by these attacks, the fact that their hybrid (which combines the smaller number of rounds from AES-128 along with the larger key size from AES-256) can be broken with such a low complexity raises serious concern about the remaining safety margin offered by the AES family of cryptosystems.

Hash competition round 2 candidates announced, etc.

July 24th, 2009

And then there were 14…

The round two candidates have been selected for the NIST cryptographic hash algorithm competition. From the competition’s email list,

Date: Fri, 24 Jul 2009 09:36:00 -0400
From: “Burr, William E.”
To: Multiple recipients of list

NIST received 64 SHA-3 candidate hash function submissions and accepted 51 first round candidates as meeting our minimum acceptance criteria. We have now selected the following 14 second round candidates to continue in the competition:[...]

Noticeably absent is MD6, which the MD6 team foreshadowed earlier this month on the competition’s email list.

Date: Wed, 1 Jul 2009 10:55:30 -0400
From: “Ronald L. Rivest”
To: Multiple recipients of list
Subject: OFFICIAL COMMENT: MD6

[...]
Thus, while MD6 appears to be a robust and secure cryptographic hash algorithm, and has much merit for multi-core processors, our inability to provide a proof of security for a reduced-round (and possibly tweaked) version of MD6 against differential attacks suggests that MD6 is not ready for consideration for the next SHA-3 round.
[...]

I noted the competition in this old post.

Update: NIST has issued a report on the first round of the hash competition. Additionally, the round 2 candidate submission packages have been updated if tweaks were made to these packages by their authors.

-

On a side note, at the beginning of the month, NIST released a document trying to elicit discussion on algorithm transition strategies and timelines as we approach the deprecation of 80 bit crypto stacks for Federal agency purposes as well as the world at large. Per the announcement,

Comments are requested on the white paper “The Transitioning of Cryptographic Algorithms and Key Sizes” by August 3, 2009. Please provide comments to CryptoTransitions@nist.gov.

I actually enjoyed skimming this document. Besides the broad transition discussion, this document really provides useful summaries of the various cryptographic algorithms allowed for FIPS 140 purposes and also in common use out there in the world. It pulls together concise use-oriented descriptions of the various algorithms and the documents that discuss those algorithms, including the normal uses of these algorithms and their strengths for these uses. We often talk about crypto stacks, and this document makes it easy to see a crypto stack. Also, it makes sense that this topic is being hashed out prior to FIPS 140-3.

Update: NIST posted the comments received up to 2009-07-24 on the transition paper. This was updated to comments received through 2009-08-14.

-

Rather than creating a new post, I figured I would add these here.

NIST has published a draft summary of the Cryptographic Key Management Workshop. As per the announcement,

NIST announces that the Draft NIST Interagency Report 7609, Cryptographic Key Management Workshop Summary (June 8-9, 2009), is available for public comment. The Cryptographic Key Management (CKM) workshop was initiated by the NIST Computer Security Division to identify and develop technologies that would allow organizations to leap ahead of normal development lifecycles to vastly improve the security of future sensitive and valuable computer applications. The workshop was the first step in developing a CKM framework. This summary provides the highlights of the presentations, organized by both topic and by presenter.[...]

NIST has published a draft of SP 800-38E, dealing with NIST approval of the XTS mode of operation for AES, for comment. As per the announcement,

NIST announces that the Draft NIST Special Publication 800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Block-Oriented Storage Devices, is available for public comment. This document approves the XTS-AES mode of the AES algorithm by reference to IEEE Std 1619-2007, subject to one additional requirement, as an option for protecting the confidentiality of data on block-oriented storage devices. This mode does not provide authentication, in order to avoid expansion of the data; however, it does provide some protection against malicious manipulation of the encrypted data.

Update: NIST has published SP 800-56B, as described here.

NIST announces the completion of Special Publication (SP) 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography. This Recommendation provides the specifications of key establishment schemes that are based on a standard developed by the Accredited Standards Committee (ASC) X9, Inc.: ANS X9.44, Key Establishment using Integer Factorization Cryptography. SP 800-56B provides asymmetric-based key agreement and key transport schemes that are based on the Rivest Shamir Adleman (RSA) algorithm.

NIST has published SP 800-102 and SP 800-120, as described here.

NIST announces the completion of Special Publication 800-102, Recommendation for Digital Signature Timeliness. Establishing the time when a digital signature was generated is often a critical consideration. A signed message that includes the (purported) signing time provides no assurance that the private key was used to sign the message at that time unless the accuracy of the time can be trusted. With the appropriate use of digital signature-based timestamps from a Trusted Timestamp Authority (TTA) and/or verifier-supplied data that is included in the signed message, the signatory can provide some level of assurance about the time that the message was signed.

The National Institute of Standards and Technology (NIST) is pleased to announce the release of Special Publication 800-120. Recommendation for EAP Methods Used in Wireless Network Access Authentication. This Recommendation formalizes core security requirements for EAP methods when employed by the U.S. Federal Government for wireless authentication and key establishment.

Quickies – FIPS 186-3 etc., other notes, metro, etc.

June 11th, 2009

Just a few quick and mostly old notes accumulated over the last few months…

FIPS 186-3 has been released, as announced here.

This notice announces the Secretary of Commerce’s approval of Federal Information Processing Standard (FIPS) Publication 186–3, Digital Signature Standard (DSS). FIPS 186–3 is a revision of FIPS 186–2. The FIPS specifies three techniques for the generation and verification of digital signatures that can be used for the protection of data: the Digital Signature Algorithm (DSA), the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Rivest-Shamir-Adelman (RSA) algorithm. Although all three of these algorithms were approved in FIPS 186–2, FIPS 186–3 increases the key sizes allowed for DSA, provides additional requirements for the use of RSA and ECDSA, and includes requirements for obtaining the assurances necessary for valid digital signatures. FIPS 186–2 contained specifications for random number generators (RNGs); this revision does not include such specifications, but refers to NIST Special Publication (SP) 800–90 for obtaining random numbers.

[...]FIPS 186–3 allows the use of 1024, 2048 and 3072-bit keys. Other requirements have also been added concerning the use of ANS X9.31 and ANS X9.62. In addition, the use of the RSA algorithm as specified in Public Key Cryptography Standard (PKCS) #1 (RSA Cryptography Standard) is allowed.

In the announcement, some of the changes between the last draft and the final document are covered in a comments received and NIST response format. I found the most interesting NIST responses to be…

This permits the use of a public key algorithm and key size that is stronger in security than a hash algorithm, so long as both provide sufficient security for the digital signature process. The use of hash algorithms that provide equivalent or stronger security than the public key algorithm and key size is still encouraged as a general practice.

NIST studied the suggestion and decided not to impose further restrictions on the selection of the public exponent e. Such restrictions would negatively impact NIST’s Cryptographic Module Validation Program (CMVP) by precluding the validation of currently accepted implementations without providing a significant increase in security.

NIST reviewed the comments and made the appropriate changes to ensure alignment with respect to the generation and management of ECDSA domain parameters. NIST deleted the statement ‘‘ANSI X9.62 has no restriction on the maximum size of [the cofactor]’’, since the current version of X9.62 imposes limitations on the size of the cofactor. NIST also revised statements regarding elliptic curve domain parameter generation for purposes other than digital signature generation.

I commented on an early draft here and mentioned a later draft here.

Update:Annex A and Annex C of FIPS 140-2 have been updated to reference FIPS 186-3.

The algorithm testing tool has been updated to include testing for FIPS 186-3 algorithms, with some exceptions. As found the announcements,

New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS8.0). This version of the CAVS tool activates the FIPS 186-3 DSA2 validation testing with the exception of generation and validation of provably prime domain parameters p and q and canonical generation and validation of domain parameter g. It also requires the IUT to specify the assurances necessary for valid digital signatures specified in FIPS 186-3.

The exceptions to the algorithm testing tool are vendor affirmed for now, as per an update to the FIPS 140-2 Implementation Guidance.

Validation testing for FIPS 186-3, Digital Signature Standard (DSS) is separated into the three digital signature algorithms. Validation testing is available for FIPS 186-3 DSA, with the exception of the domain parameter generation and validation method listed above. These methods, along with FIPS 186-3 ECDSA and RSA, will require vendor affirmation until validation testing is available in the CAVS tool.

Update: NIST has released a new version of the algorithm testing tool (8.1) that “addresses several minor modifications and enhancements to CAVS including the Addition of a cover letter template, the addition of more efficient elliptic curve routines for NIST binary (e.g.., B-163 and K-571) curves, and the modification of several minor issues.”

-

Speaking of FIPS, the FIPS 140-2 implementation guidance (IG) has been updated over the last few months. There has been much in the way of important and clarifying guidance, translating both “FIPS lore” and the forward thinking on algorithms/protocols as well as revs to FIPS 140 into the current requirements.

New Guidance
o04/01/09: 3.2 Bypass Capability in Routers
o04/01/09: 9.5 Module Initialization during Power-Up
o03/24/09: 7.9 Procedural CSP Zeroization
o03/10/09: 1.14 Key/IV Pair Uniqueness Requirements from NIST SP 800-38D
o03/10/09: 5.3 Physical Security Assumptions
o03/10/09: 7.8 Key Generation Methods Allowed in FIPS Mode

Modified Guidance
o03/10/09: G.1 Request for Guidance from the CMVP – Updated NIST POC.
o03/10/09: G.5 Maintaining validation compliance of software or firmware cryptographic modules – Updated references to firmware and hybrid modules.
o03/10/09: G.13 Instructions for completing a FIPS 140-2 Validation Certificate – Updated examples.
o03/10/09: 1.9 Definition and Requirements of a Hybrid Cryptographic Module – Updated to include hybrid firmware modules.
o03/10/09: 7.1 Acceptable Key Establishment Protocols – For Key Agreement; added the KDF specified in the SRTP protocol (IETF RFC 3711) is allowed only for use as part of the SRTP key derivation protocol. For Key Transport; wrapping a key using the GDOI Group Key Management Protocol described in the IETF RFC 3547.

I don’t think any of these are a surprise, but reading through it might be useful. Much has been set done cleanly here, with the possible exception of IG 9.5, which seemed more confusing than clarifying to me, but maybe that was a case of my (unfortunately) “knowing” too much about the FIPS world. Anyway, the changes to or additions of IGs 1.9, 7.1, 7.8, and 1.14 are perhaps of the most interest.

Since I have been coming at things from a more deployment side these days, I think IG 5.3 helps to illustrate how to interpret FIPS 140-2 validation results as applied to the selection and deployment of FIPS modules.

The four physical security levels of FIPS 140-2 are focused on the protection of the modules CSPs by the module itself independent of the environment the module is deployed. Therefore selection of a security level is greatly influenced by the environment the module is to be deployed. At a Level 1 security level, which does not itself provide physical security protection, in the right environment, may be an acceptable solution because the environment provides the required physical security protection features.

In this same deployment regard, IG 1.14 makes the following note.

2. The standard sets the minimum security requirements. The buyer is free to demand that the module allows for longer names. Users should be smart enough to name their modules in such a way that name collisions become extremely rare.

Also, for the old timers, the following was an area of debate back in the day. Now it is officially documented in an IG 7.8.

To be used in FIPS mode, a secret value K can be any value of the form:

K = U XOR V, (1)

where the components U and V are of the same length as K14, are “independent” of each other, and U is derived, possibly using a qualified post-processing (see below), from the output of an approved RNG in the module that is generating K. In addition, each component may be a function of other values (e.g., U = F(U’), or V = F(V’)).

The security strength of the generated value K is equal to the larger of the security strengths of U and V. In general, the security strength of K is determined by the security strength of U, and the security strength of U is the minimum of the length of U (and K) and the security strength of the RNG used to generate U. Therefore, the length of U (and K), and the security strength of the RNG used to generate U shall meet or exceed the security strength required for K. However, a vendor can claim that the security strength of the generated value K is determined by the security strength of V if it can be demonstrated that V has a higher security strength than U.

Update: NIST released revised implementation guidance. Besides “certificate annotation examples” added to a few sections, there was the following modification.

08/04/09: 7.1 Acceptable Key Establishment Protocols – For Key Agreement; removed the KDF specified in the SRTP protocol (IETF RFC 3711). For Key Transport; added reference to EAP-FAST and PEAP-TLS.

-

Since I am on this topic, I guess a quick note that a number of new revs of the CAVS were released in months prior is in order. Most were bugfixes and tweaks, but there were some additions to supported algorithms. E.g.,

[04-15-09] — New release of the CAVS algorithm validation testing tool to the CST Laboratories (CAVS7.4). This version of the CAVS tool adds the capability to test DRBG (NIST SP 800-90) implementations that do not have the optional reseed function.[...]

[03-12-09] — New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.1). In addition to minor modifications to enhance the tool, Version 7.1 of the CAVS tool adds testing for the draft of FIPS 186-3, Digital Signature Standard, Digital Signature Algorithm and file formating changes to the NIST SP 800-90 (DRBG) files to make them more similar to those used for other algorithms. As of the CAVS 7.1 release date, FIPS 186-3 is still in draft. No validations will be processed for this algorithm.

Update: NIST released the CAVS Management Manual. As per the announcements,

[08-17-09] — Posting of the CAVS Management Manual. The purpose of the CAVP Management Manual is to provide effective guidance for the management of the CAVP and other parties in the validation process.[...]

-

Switching direction, upgrading Gnome from 2.24 to 2.26 on FreeBSD through the ports went mostly smoothly. As always, follow the FAQ. I had been using xulrunner for a while, but I was happy to see this change for the removal for FF2.

A FreeBSD port of libxul-1.9 has been added as an alternative Gecko provider to Firefox 2. This can be used by setting WITH_GECKO=libxul in /etc/make.conf.

And, on Ubuntu, this deadlock hit me after upgrading to Ubuntu Jaunty (2.6.28-11.server). I have been manually loading the padlock drivers for quite some time via /etc/modules. To avoid the issue, I added in manual loading of the generic kernel crypto implementations for aes, sha1, and sha256 prior to loading the padlock drivers.

-

Moving along, this gives me deja vu, yet made me laugh. (Please consider avoiding that previous link and the first link in the following blockquote’d text if you mind profanity.)

[...]Listen to his comedy bit about the DC metro system, which is he says is “the [...] Tron compared to NYC subways[...]

Having lived both in NYC and DC metro areas and having ridden both the NYC subway and the DC metro quite a bit, I think there are two points to make about the DC Metro system.

  1. The DC Metro is minor in scope compared to the NYC subway. Not only is it a fraction of the size moving a fraction of the people, but it is only part-time.
  2. The DC Metro system is designed like an X, and much of that X only has a single track going in each direction. So, if anything goes wrong in your part of the X or the center of the X, well, lets just say you are out of luck.

Now, because of point 2, even if DC blows up in size and develops a late-night night-life, it would be quite difficult to do away with point 1 in any significant fashion without some fundamental design changes. Even if you could magically do away with unexpected problems in the system (and, yes, that would have to include rainy and snowy days), you are stuck juggling trains between single tracks best case or shutting down parts of the line and running shuttle buses worst case for basically any line maintenance, significantly impacting service on those parts of the system and on the overall system as you move closer to the center of the X. This becomes even more acute due to the increased wear and tear that lovely, underground center of the X suffers, especially as you ramp up service to handle more people or longer hours.

The NYC subway system, by contrast, looks like a bunch of parallel lines that crisscross here and there, and these multitudes of lines generally have multiple tracks supporting each direction. While there may be sparse coverage at some points (e.g., parts of Queens come to mind) and a large concentration of lines at other points (e.g., Manhattan), you still tend to end up with lots of independent enough ways to route around much of the maintenance work and unexpected problems such that the effect on the overall system tends to be quite limited and interruptions to the particular parts undergoing work or suffering issues can be mitigated/minimized (e.g., the handling of maintenance work on the 7 line happening right now), even in spite of 24/7 operation.

Like so much else that varies between NYC and its neighbors, there is a big difference in the scale/scalability and availability requirements of public transportation for an enormous 24/7 city accustomed to public transit and a large 18/7 city accustomed to the beltway. So, when it comes down to how to spend limited resources, one gets beauty sleep, the other keeps on keeping on. :)

-

Finally, it has been a while since I have pointed out notably pleasant customer service experiences. So, here is some praise for the LIRR cleaning crew in Penn Station left in a comment.

To Whom It May Concern, I would like to praise all the cleaning men and women who work in the station. They all do a fantastic job on keeping the station clean.

Quick note – a crack at building TC 6.1a on FBSD 7.1

March 29th, 2009

Prompted by a comment and this rainy day…

Myself, I mostly think of TrueCrypt as Windows software today, so I can’t say I use it much on FreeBSD. However, I haven’t had much trouble getting TrueCrypt 6.1a to build on FreeBSD 7.1, even though I may not use the end result.

So, starting off with a pretty much stock FreeBSD 7.1 system with Gnome 2.24 installed as my test environment, I was able to do something like the following to get TrueCrypt 6.1a to build from source.

I downloaded, verified, and extracted the TrueCrypt 6.1a source.

I took a look at the “Readme.txt” in the root of the extracted TrueCrypt source tree and ensured that I met the requirements listed in the “Requirements for Building TrueCrypt for Linux and Mac OS X” section. I found the bulk of what may be missing (I say “may be missing” because most dependencies were already met in this test setup) readily available in the FreeBSD ports tree (e.g., gmake, fusefs-kmod, fusefs-libs, pkg-config, wxgtk). I had PKCS#11 header files lying around, but I also tried downloading fresh ones (e.g., pkcs11.h, pkcs11f.h, pkcs11t.h) from the RSA ftp site.

One important note here – the FreeBSD ports has split wxWidgets into multiple versions/flavors. After glancing at the root TrueCrypt makefile, I decided to go with “wxgtk28-unicode” from the FreeBSD ports for the TrueCrypt build. This choice has later implications, as the TrueCrypt build defaults to the use of the generic “wx-config”, which will not exist when using one of the wxWidgets from the FreeBSD ports, since “wx-config” is renamed in accordance with the specific version/flavor of the installed FreeBSD port. While I didn’t notice the “Readme.txt” calling out that this can be tweaked, the root TrueCrypt makefile is clear here and the choice of “wx-config” can be conveniently overridden, as noted next.

With the dependencies done, I then followed the build instructions for Linux and Mac OS X in the “Readme.txt”, interpreting them for my environment. For my particular test setup, there were three main tweaks here – use “gmake” (GNU make) rather than “make” (the stock FreeBSD make), set “WX_CONFIG” appropriately (since I was using “wxgtk28-unicode”, I set this to “wxgtk2u-2.8-config” overriding the default “wx-config”), and set “PKCS11_INC” appropriately since the PKCS#11 header files I wanted to use were not in the default include paths used by the TrueCrypt build (I pointed this to the directory where I had the PKCS#11 header files). So, from the root directory of the TrueCrypt source tree, I ran something like “gmake WX_CONFIG=wxgtk2u-2.8-config PKCS11_INC=<path to downloaded header files>”.

After building successfully and prior to running the resulting “truecrypt” executable (found in “./Main” in the source tree), I checked to see if the FUSE kernel module was loaded. It wasn’t, so I loaded it (e.g., “sudo kldload /usr/local/modules/fuse.ko”).

Then I ran “truecrypt”. I ran its crypto tests, created a new TrueCrypt container with a UFS filesystem, and mounted, dismounted, and created/modified/deleted some files on this container. Everything appeared to be working.

And that is about all I can say about TrueCrypt 6.1a on FreeBSD 7.1. :)

Notes – ff3, -n, ps, misc tools, lsof/fstat, etc

March 17th, 2009

Since there was some interest in the previous post, here are a few more notes and tips. Most often I forget to mention those standard tools we all take for granted, so I threw in some of those in as well. Oh, and I won’t be keeping up this extremely rapid posting rate (i.e., 2 in about week). ;) (Note: If I played with any of what is written here, it was on Ubuntu 8.10 or FreeBSD 7.1.)

  1. By default in Firefox 3, when opening Tools->Add-ons, Firefox sends queries to *.mozilla.com in order to populate the “Get Add-ons” pane. This pane and its “paneful” behavior can be disabled by setting the “extensions.getAddons.showPane” preference to “false” through, say, “about:config”.
  2. Using the “-n” option is your friend for listing network address information with utilities like “lsof” (e.g., “lsof -n”), “netstat” (e.g., “netstat -an”), and “iptables” (e.g., “iptables -n –list”), as it prevents the resolving of numeric network addresses, which can be annoying, revealing, and time consuming.
  3. Dislike when ps truncates rather than wraps? The “w” (wide output – 132 columns) or “ww” (unlimited width) option is your friend. If you need finer-grained control than that for some reason, you could try setting a “COLUMNS” environment variable in your shell to override the width determined by ps automatically. Or, in a nod to a later bullet point in this post, you may have additional ps options, like the “–cols” or “–columns” options that can be used to specify these settings in the GNU/Linux ps world.
  4. In much of the *n[iu]x world, if you want to know how many lines, words, or bytes are in a file (or stdin), “wc” is often where its at.
  5. Want to log to syslog using a command from a shell in much of the *n[iu]x world? Try “logger”.
  6. In the much of the *n[iu]x world, ldd can be used to list the shared object (i.e., dynamically linked library) dependencies of a binary. (A question of what stock commands there are available to do this came up on a non-technical mailing list I am on recently.)
  7. On GNU/Linux, lsof can be used to list open files, and it is quite a powerful utility. (A question of what stock commands there are available to do this came up on a non-technical mailing list I am on recently.) For example, “lsof +L 1″ will list all open files that have a zero link count (e.g., open files that are unlinked from the file system – this is useful to play with if you have ever wondered why you can upgrade packages/ports in place that have currently running applications).

    Now, on GNU/Linux, you can dig into “/proc”, which contains a wealth of kernel information. Browsing the contents of “/proc/[pid]” can be used to access the process information for a particular process, and, coming back to our example, this includes the contents of files open by that process – e.g., “/proc/[pid]/fd/[fd]” for files open by the process and “/proc/[pid]/exe” for the executable of the process itself, both of which can be used to access the contents of files open by the process with a zero link count.

    On FreeBSD, fstat can be used to list open files; however, it does not have quite the same flexibility as lsof. For example, listing open files with a zero link count is not simply a matter of command line options to fstat, although you could hack a script together utilizing fstat with other standard tools available on FreeBSD, hopefully unlike the following.

    #!/bin/sh
    
    # This is worse than the worst kludge. Do not use it.
    
    dofind()
    {
            # This find is ugly and potentially huge. Not to mention, pkill could
            # run amuck. Perhaps you could use info gathered from, say,
            # "ps wwe -p $pid -o command=" to help refine these searches,
            # but, like I said, all of this herein is worse than the worst kludge.
    
            find -x $mount -inum $inum -exec pkill -SIGINT -f -n -g 0 -s 0 \"find -x $mount -inum $inum -exec pkill\" \; 2>/dev/null
            return $?
    }
    
    doout()
    {
            echo "$cmd $pid $user $fd $szdv $mode $rw $inum $mount$1" `[ $1 ] || ps ww -p $pid -o command= 2>/dev/null`
    }
    
    fstat_unlink()
    {
            fstat $* 2>/dev/null | while read user cmd pid fd mount inum mode szdv rw junk; do
                    case $fd in
                            # We have the header
                            "FD")
                                    doout " CommandWithArgs"
                                    ;;
                            # We have a special
                            [!0-9]*)
                                    dofind
                                    [ $? -eq 1 ] && doout
                                    ;;
                            # We have a standard except non-inodes
                            *[0-9])
                                    dofind
                                    [ $? -eq 1 ] && doout
                                    ;;
                    esac
            done
    }
    
    fstat_unlink $*
    

    Now, FreeBSD has variants of /proc (procfs and linprocfs), but these are not quite as free with the information as on Linux. This means our example of extracting information from open but unlinked files may be a bit more involved; however, you can still fall back on standard tools on FreeBSD to do it, such as fsdb and dd. For example, once you have a list of the inodes and devices for unlinked files, then you can access FFS inode data with “fsdb -r” using its “inode” and “blocks” CLI commands to get the disk blocks of the relevant inodes, and then use “dd if= bs= count= skip=” to dump the disk blocks associated with the inode, perhaps into a file.

    Or, you could just write some code. However, if you dig into the FreeBSD ports, you will find that lsof is available there. As are tools/toolkits like foremost and sleuthkit. No need to reinvent the wheel.

  8. Little tweaks to common system applications can be tricky business in the *n[iu]x world. For example, take the stock find on Ubuntu GNU/Linux (8.10) and FreeBSD (7.1). In this particular GNU/Linux world, our find comes with a “-quit” action that can be used to exit find after it has found particular results; however, in this particular BSD Unix world, we find that our find does not support “-quit”, yet we can combine pkill with the “-exec” primary/action of find to have a “find” process kill itself after it has found particular results. A form of this use is illustrated by the kludge script above. Also, being specifically tied to this particular BSD Unix world, that same kludge script uses “-x” over the equivalent “-xdev”, but, in this particular GNU/Linux world, find provides solely “-xdev”. Yet another example, the find in this particular BSD Unix world has the “-X” option to allow for safe use with xargs, but the find in this particular GNU/Linux world sticks with the good old “-print0″ and “xargs -0″ technique.

    With all this lovely variation, it is often good practice to at least know if not use the more standard, common, portable variants of commands and their options, as you never know where you may find yourself or your scripts ending up.

  9. Having worked with iptables quite a bit of late has served to remind me of the elegance of pf. :)
  10. bangbang, baby. shell-fu.

Some notes – ff3, gpg, iptables, dhclient, printk, djbdns

March 11th, 2009

I have been lax on my note taking, but here are a few notes and tips that have come up over the last few months. (I think I did better with formatting this time, after some mockery for this post.)

  1. Firefox 3 is configured to download a BBC news feed (Bookmarks->Bookmarks Toolbar->Latest Headlines) by default. You can just remove the offending bookmark to do away with this behavior.
  2. The way import and export of OpenPGP keys with multiple sub-keys works in GnuPG (1.4.9) is a bit counter-intuitive to me. If you generate a new sub-key pair for an OpenPGP key in a GnuPG key ring and then export the public and secret components of that OpenPGP key, and then try importing that OpenPGP key into another GnuPG key ring that already has an older version of that OpenPGP key (i.e., the version prior to the addition of a new sub-key pair), the already existing and unchanged components of the OpenPGP key will remain unchanged (as expected) but only the public component of the new sub-key will be imported (as unexpected). In order to get the complete OpenPGP key imported, you will first have to delete the public and private components of the key from the key ring into which you want to merge this updated key (back up the key ring first), and then import the key. Also, you may want to (re)set the trust of the key after doing so.
  3. On FreeBSD, “pkg_deinstall” is quite helpful in pruning your installed ports tree, especially for the clean up of dependencies for ports that are being, or have been, removed – in particular the “-r” and “-R” options, which have the same meaning as with “pkg_info” (in reverse) or “portupgrade”. Also, I find running “portupgrade -an” useful to see what will be upgraded prior to actually doing the upgrades.
  4. Using a box running Ubuntu (8.10) server (without X and its children) with iptables for IP forwarding with NAT is quite easy. An extremely helpful concept to keep in mind is that, within the “filter” table (the default table), the “INPUT” and “OUTPUT” chains are for packets terminating or originating at the box respectively, while the “FORWARD” chain is for packets flowing through the box. So, say you have a box already configured with “filter” table “INPUT” and “OUTPUT” rules that make you comfortable; adding “filter” table “FORWARD” rules does not generally require modification to these existing “filter” table rules, although you may want/need to tweak things a bit for your new setup. However, you do need to remember to consider which “INPUT” and “OUTPUT” rules you also want applied to “FORWARD” rules and set things up accordingly. Also, the “nat” table is independent of the “filter” table and its rules are used to mangle packets rather than filter them.

    With that said, this HOWTO contains a helpful example set of rules for IP forwarding with NAT using iptables.

  5. On Ubuntu (8.10) server (without X and its children), dhclient has the ability to run scripts before (“/etc/dhcp3/dhclient-enter-hooks.d/”) or after (“/etc/dhcp3/dhclient-exit-hooks.d/”) it configures interfaces from the information gathered through DHCP, a nice supplement to the good old “/etc/network/pre-if-up.d/” and “/etc/network/if-up.d/”, and “/etc/network/pre-if-down.d/” and “/etc/network/if-down.d/”. So, for example, you can use this to reload your iptables rules, if, say, you have rules tied to information that was configured via DHCP. Or, to invoke ddclient, if you have a public IP address assigned via DHCP and use a dynamic DNS service.

    E.g. a very generic ddclient script,

    sudo vi /etc/dhcp3/dhclient-exit-hooks.d/ddclient
    

    And add something like the following to it,

    (Note: This is an illustration and has not been tried by me exactly as it is here. Actually, ddclient seems like a rather poor example for this, but oh well.)

    # Note: only really makes a slight bit of sense if an interface
    # is configured with a DHCP assigned public IP address, and that
    # is the interface used by ddclient.
    
    DDCLIENT_CONF=/etc/ddclient.conf
    DDCLIENT_CACHE=/var/cache/ddclient/ddclient.cache
    DDCLIENT_USER=ddclient
    
    rerun_ddclient() {
            [ -e /usr/sbin/ddclient ] || return
    
            [ -e $DDCLIENT_CONF ] || return
    
    # Note: ddclient performs this sort of check itself as well.
            if [ -e $DDCLIENT_CACHE ] && [ -n "$old_ip_address" -a "$old_ip_address" = "$new_ip_address" ]; then
                    return
            fi
    
    # (I know, not /bin/sh -e, but habit.)
    
    # Runs ddclient as user other than root, but you must have
    # configured such a user and set ddclient up to work with them.
    #       /usr/bin/sudo -u $DDCLIENT_USER /usr/sbin/ddclient >/dev/null 2>&1 || true
    
    # ddclient is run as root here.
            /usr/sbin/ddclient >/dev/null 2>&1 || true
    }
    
    ddclient_whattodo() {
            case $reason in
                    BOUND|RENEW|REBIND|REBOOT)
                            rerun_ddclient
                            ;;
                    EXPIRE|FAIL|RELEASE|STOP)
                            ;;
                    *)
                            ;;
            esac
    }
    
    ddclient_whattodo
    

    The manpage for “dhclient-script” details the various “$reason”’s for why dhclient-script is being invoked as well as the other variables available, such as “$new_ip_address” and “$old_ip_address”, that can be used to determine the actions you want your scripts to take. Also, “/sbin/dhclient-script” uses “run-parts –list” to generate the list of scripts to be invoked, and this list is alphabetical. So, if your scripts need to be invoked in a certain order, keep that in mind.

    Note: While outside the scope being discussed here, if you are using the Gnome (2.24) NetworkManager to manage your network interfaces, then dhclient is invoked with the “-sf” option to override the use of the standard “/sbin/dhclient-script” with “/usr/lib/NetworkManager/nm-dhcp-client.action”, which does not run the scripts in “/etc/dhcp3/dhclient-enter-hooks.d/” or “/etc/dhcp3/dhclient-exit-hooks.d/”. You may still make due with using the good old “/etc/network/pre-if-up.d/” and “/etc/network/if-up.d/”, and “/etc/network/pre-if-down.d/” and “/etc/network/if-down.d/”, which have generally been fine for my use cases. Or, perhaps you could probably write a script to monitor D-Bus for a “PropertiesChanged” signal from “org.freedesktop.NetworkManager.DHCP4Config” and then check if a new IP has been assigned. Or, maybe there is a more standard plugin mechanism. Who knows, I haven’t played with it.

  6. On Ubuntu (8.10) server (without X and its children), dhclient has this habit of overwriting “resolv.conf” by default. This is useful in many cases, but, if not, you can override it creating a custom “make_resolv_conf()” function in “/etc/dhcp3/dhclient-enter-hooks.d”.

    E.g.,

    sudo vi /etc/dhcp3/dhclient-enter-hooks.d/donotmodifyresolvconf
    

    And add something like the following to it,

    make_resolv_conf() {
            return
    }
    

    Note: While outside the scope being discussed here, if you are using the Gnome (2.24) NetworkManager to manage your network interfaces, then, as noted previously, dhclient is invoked with the “-sf” option to override the use of the standard “/sbin/dhclient-script”. So, to configure this sort of DHCP settings for a particular interface in Gnome using the NetworkManager, you could instead go to Main Menu->System->Preferences->Network Configuration, select the interface you want to configure and click “Edit”, go to the “IPv4 Settings” tab, and select “Automatic (DHCP) addresses only” along with filling in the static DNS information. Also, see this for underlying details of the settings available.

  7. The Linux kernel “printk” setting determines what kernel messages will be displayed on the console. On a stock Ubuntu (8.10) server install (without X and its children, and using the stock syslog), one can use “sysctl kernel.printk” or “cat /proc/sys/kernel/printk” to display this setting, which will look something like “4 4 1 7″. What these numbers mean is as follows,

    include/linux/kernel.h

    #define	KERN_EMERG	"<0>"	/* system is unusable			*/
    #define	KERN_ALERT	"<1>"	/* action must be taken immediately	*/
    #define	KERN_CRIT	"<2>"	/* critical conditions			*/
    #define	KERN_ERR	"<3>"	/* error conditions			*/
    #define	KERN_WARNING	"<4>"	/* warning conditions			*/
    #define	KERN_NOTICE	"<5>"	/* normal but significant condition	*/
    #define	KERN_INFO	"<6>"	/* informational			*/
    #define	KERN_DEBUG	"<7>"	/* debug-level messages			*/
    

    kernel/printk.c

    /* printk's without a loglevel use this.. */
    #define DEFAULT_MESSAGE_LOGLEVEL 4 /* KERN_WARNING */
    
    /* We show everything that is MORE important than this.. */
    #define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */
    #define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */
    
    int console_printk[4] = {
    	DEFAULT_CONSOLE_LOGLEVEL,	/* console_loglevel */
    	DEFAULT_MESSAGE_LOGLEVEL,	/* default_message_loglevel */
    	MINIMUM_CONSOLE_LOGLEVEL,	/* minimum_console_loglevel */
    	DEFAULT_CONSOLE_LOGLEVEL,	/* default_console_loglevel */
    };
    

    So, at the time of this writing, we see that “kernel.printk=”7 4 1 7″” is the 2.6 Linux kernel default; on Ubuntu (8.10), “kernel.printk” is set to “4 4 1 7″ by default (see “/etc/sysctl.d/10-console-messages.conf”). Let’s say I want “kernel.printk” to be set to “6 4 1 7″.

    There are lots of ways to accomplish this. Besides “klogd -c” or the old “echo /proc/sys/kernel/printk”, sysctl can be used to set “/proc/sys” parameters at runtime (e.g., “sudo sysctl kernel.printk=”6 4 1 7″”) on Ubuntu (8.10), but such changes are lost at reboot and let’s say I want this setting applied at each boot. Ordinarily, if you want certain “/proc/sys” parameters to be automatically set at boot and you are not doing so anywhere else (e.g., in some other rc.d script), you either add files in “/etc/sysctl.d” containing the parameter settings, or you add/modify parameters in “/etc/sysctl.conf”.

    Now, on Ubuntu (8.10), the settings in “/etc/sysctl.d/*.conf” are applied after those in “/etc/sysctl.conf”, which means “/etc/sysctl.d/*.conf” settings will override “/etc/sysctl.conf” settings. Since Ubuntu (8.10) uses “/etc/sysctl.d/10-console-messages.conf” to set “kernel.printk=”4 4 1 7″”, I need to either edit that conf or add my own that is set after that one. To do things “properly,” I should go with the latter, by, say, copying “10-console-messages.conf” to “60-console-messages.conf” (60 is the standard prefix for user customizations) and then editing “60-messages-console.conf” to contain “kernel.printk=”6 4 1 7″”.

    I guess, rather than overriding “printk” defaults, I could instead configure the stock syslog by, say, modifying its default configuration file (“/etc/syslog.conf”) to display log entries to the console, and this could be used to cover both system logs and kernel messages. Leaving alone the Ubuntu “kernel.printk” default of “4 4 1 7″, by adding a line like “kern.info;kern.!err /dev/console”, kernel messages of priority “info” (6) or more critical should be displayed to the console (the “kern.!err” is there because we are already displaying “err” and higher priority messages by virtue of the Ubuntu default “kernel.printk” configuration). Going broader than just the kernel, a line like “*.info /dev/console” would cover all system log entries of priority “info” or more critical. Generally though, if I want kernel messages dumped to the console, I work within the parameters of the kernel itself, namely “kernel.printk”.

    Coming back to iptables, the “log-level” option of iptables “LOG” rules can be used to tweak what will hit the console. Now, unless iptables is told to use a specific loglevel, the system default seems to be used. So, with the “4 4 1 7″ setting used by default on Ubuntu (8.10), iptables “LOG” rules without the “–log-level” option will not result in console messages, and only those “LOG” rules with a “–log-level err” or more serious will hit the console. With the “7 4 1 7″ kernel default, iptables “LOG rules” without the “–log-level” option will result in console messages, and only those “LOG” rules with a “–log-level debug” will not hit the console.

    Tying this into syslog a bit, if, say, there are quite a bit of kernel log entries generated by iptables and whittling back the “LOG” rules is not satisfactory, syslog rules could be used to split the kernel logs into pieces to help with manual review and remove redundant logging. So, using the “–log-level debug” in “LOG” rules and adding an entry like “kern.=debug -/var/log/kern.debug” in “/etc/syslog.conf” would place all iptables log entries (and other kernel messages with a priority of “debug”) into “/var/log/kern.debug”, while the default “/var/log/kern.log” would still contain all kernel messages (and the default “/var/log/debug” would still contain most debug log entries and the default “var/log/syslog” would still contain most log entries). Or, you could split the kernel logs up into, say, “kern.debug”, “kern.info;kern.!err”, and “kern.err”, and then use “–log-level” rules to determine to which kernel log the iptables “LOG” rules are logged. Combining such a split of the kernel logs with removing kernel messages from the default logs could help reduce redundancy as well, although care should be taken because sometimes applications depend on the default logs being, well, set to the defaults. (On a side note, if you are doing more than just simple basics with syslog, it may be time to consider replacements like rsyslog and syslog-ng.)

    (Whew, I hope I typed all that correctly.)

  8. Having had to rebuild djbdns a bit recently and remembering this post, I updated “/etc/event.d/svscan” to handle a system shutdown a bit friendlier.

    E.g.,

    sudo vi /etc/event.d/svscan
    

    And add something like the following to it,

    (Note: The following is an example and has not been tried by me exactly as it is here. FYI, “svscanboot” might be located somewhere other than “/command”.)

    # svscan - daemontools -- http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12
    #
    
    # This service maintains an svscan process from the point the system is
    # started until it is shut down again.
    
    start on runlevel 2
    start on runlevel 3
    start on runlevel 4
    start on runlevel 5
    
    stop on runlevel 0
    stop on runlevel 1
    stop on runlevel 6
    
    exec /command/svscanboot
    respawn
    

Quickies – zero, conficker, https, djbdns, fashion

February 27th, 2009

This month has certainly been interesting.

A couple of zero days in widely deployed software were discovered by virtue of active exploitation out there in the world…

An Adobe Acrobat and Reader zero day [demo exploits], with an official patch expected next month (there is an unofficial patch).

A critical vulnerability has been identified in Adobe Reader 9 and Acrobat 9 and earlier versions. This vulnerability would cause the application to crash and could potentially allow an attacker to take control of the affected system. There are reports that this issue is being exploited.

Adobe is planning to release updates to Adobe Reader and Acrobat to resolve the relevant security issue. Adobe expects to make available an update for Adobe Reader 9 and Acrobat 9 by March 11th, 2009. Adobe is planning to make updates for Adobe Reader 7 and 8, and Acrobat 7 and 8, available by March 18th.[...]

Update: Adobe has released the security updates for Acrobat and Acrobat Reader 9.

A potential Microsoft Excel zero day, with more information to be determined.

Microsoft is investigating new public reports of a vulnerability in Microsoft Office Excel that could allow remote code execution if a user opens a specially crafted Excel file. At this time, we are aware only of limited and targeted attacks that attempt to use this vulnerability.

As always, exploiting vulnerabilities for which patches are available is working quite nicely too – just look at Conficker having a ball.

Why Conficker has been able to proliferate so widely may be an interesting testament to the stubbornness of some PC users to avoid staying current with the latest Microsoft security patches  [2].  Some reports, such as the case of the Conficker outbreak within Sheffield Hospital’s operating ward, suggest that even security-conscious environments may elect to forgo automated software patching, choosing to trade off vulnerability exposure for some perceived notion of platform stability [8].   On the other hand, the density of where the vast bulk of Conficker victims are concentrated may also suggest other reasons, such as the wide use of unregistered (pirated) Windows releases, which Microsoft does not patch [9].  

Browser usability with https continues getting hammered as well.

This tool provides a demonstration of the HTTPS stripping attacks that I presented at Black Hat DC 2009. It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. For more information on the attack, see the video from the presentation below.

The djbdns package has come under fire, of particular note.

Summary: Weaknesses in dnscache’s outgoing query management and caching policies allow an attacker to poison arbitrary DNS records in far less time than previously believed possible.
Versions Effected: All current versions of djbdns (< =1.05)

(And, now I know about zinq.)

And, to end on a lively, off-topic note, fall fashion in New York is usually a favorite of mine, and the Fall 2009 season combined that general preference with up my alley trends (already visible on the streets of New York) – comforting protective and edgier futuristic clothing, dark somber and rich powerful colors (e.g., royal blue, plum purple, forest green), playing with construction and textures (e.g., velvet, tweed, leather, satin), asymmetrical geometrical strong-shouldered architectural designs. Because of these trends, many shows had at least a few pieces that I loved, making for my much wider appreciation of the designs of a variety of designers this season. Some of my favs…

  • Yet again, Proenza Schouler – This collection veered slightly softer and perhaps nodded to their earlier days, yet still maintained the edge and architecture I have come to love. In a season where those I thought would shine seemed to go astray, these guys hit the mark.
  • Rodarte – This collection had singular point of view, with the same silhouette and structure throughout; however, the play with construction, textures, and even a pop of color kept it so interesting that I could not wait to see what would come next.
  • Ralph Lauren – This collection was like walking out into a clean, clear, crisp fall day and inhaling deeply. I said it over and over – it feels like a breath of fresh air. The simplicity, elegance, and beauty of the clothing was remarkable.

Of course, given the trends and my high expectations, I must note there were a number of train wrecks out there too. The two main categories I saw: 1) designs that looked plain silly, gaudy, and/or obnoxious, a way too literal translation of the 1980s; and 2) designs that looked stiff, heavy, and/or just plain burdensome, too much like wearing actual medieval armor, scratchy carpeting, or sound absorbing curtains.