D-kriptik Blog

So, I recently saw Juno for the first time, and was surprised and happy to hear Kimya Dawson permeate the soundtrack. And, I ate at wd~50, which was, well, an experience - highly recommended if you want to try something truly new.

Anyway, yes, still here. Unfortunately, this rare act of posting will be limited to a quickie - a few miscellaneous items accumulated over a couple of months.

-

A few headaches…

1. Wow, just wow.
   

   The result of this is that for the last two years (from Debian’s “Etch” release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys.

   Update immediately. And be sure to do things such as regenerate all persistent keys that used random data taken from the vulnerable Debian OpenSSL during their generation - some of this type of work is handled automatically when updating your packages (e.g., OpenSSH server keys), but only you know what you have done outside this automated window.

2. I booted up a Windows XP box only to find that some resource of the Logitech QuickCam software had become corrupted, and this resulted in a nasty msi installer loop hitting the box as soon as a user logged in. I found this tool extremely useful in cleaning up the mess.
   

   [..]With the Windows Installer CleanUp Utility, you can remove a program’s Windows Installer configuration information. You may want to remove the Windows Installer configuration information for your program if you experience installation (Setup) problems. For example, you may have to remove a program’s Windows Installer configuration information if you have installation problems when you try to add (or remove) a component of your program that was not included when you first installed your program.

3. Much to my very unpleasant surprise, I upgraded a server over here from Ubuntu Gutsy to Hardy and discovered networking for Xen DomU’s in Ubuntu Hardy 8.04 is somewhat broken. I ended up using the 2.6.24-17-xen kernel from the hardy-proposed repository, but you could also just stick with the Gutsy Xen kernel for DomU’s.
4. When I upgraded to Gnome 2.22 on a particular FreeBSD 7.0 system, certain things, like the clock applet, did not work. This was due to the dbus daemon not being started. Then, the hal daemon and Gnome did not want to play nice together. This page provided the information necessary to get them playing nice - in this particular instance, not mounting procfs was the problem.

Side note, I was helping someone install Ubuntu recently, and it brought to my attention yet again how much I take what I consider to be basic skills for granted when using *nix. Small things, like running an executable from within your environment path versus by directly specifying the path (the most confusing to many example of this seems to be trying to run an executable in the current working directory), are just not common knowledge. Even the whole command line itself is often scary and bizarre to people. This makes it extremely difficult to provide useful guidance for people to blindly follow (posts on this blog should never be assumed to provide step-by-step instructions - they are just some basic notes at best, as extremely helpful comments like this make obvious). And, even Ubuntu is not as trivial to use as it would appear to many that work in the *nix world.

-

Three useful Ubuntu and FreeBSD pages…

USN.

These are the Ubuntu security notices that affect the current supported releases of Ubuntu.[...]

FreeBSD VuXML.

Security issues that affect the FreeBSD operating system or applications in the FreeBSD Ports Collection are documented using the Vulnerabilities and Exposures Markup Language (VuXML).[...]

FreeBSD Security Advisories.

This web page contains a list of released FreeBSD Security Advisories.[...]

-

Story-telling is one of the fundamental tools in a teacher’s toolkit. Having done quite a bit of consulting, I have learned how invaluable a good story is to driving home particular points and building relationships. There is something fundamental about how stories effect us, perhaps stemming from our innate ability to empathesize and our massive pattern recognition horse-power.

Anyway, this site has a useful set of stories. [via exi]

Here are some stories, analogies, research findings and other examples that provide wonderful illustrations for learning, and inspiration for self-development.

In fact, the first story mirrors a recent post.

An old lady had a hearing-aid fitted, discreetly, hidden underneath her hair.

A week later she returned to the doctor for her check-up.

“It’s wonderful - I can hear everything now,” she reported very happily to the doctor.

“And is your family pleased too?” asked the doctor.

“Oh I haven’t told them yet,” said the old lady, “And I’ve changed my will twice already..”

This reminds me of a story I often tell about someone I met a while back, a graduate student in psych. She was studying aspects of the initial meeting/courtship routines of people, and would go out to bars and such and interact with potential suitors. Here these suitors were, following their typical pickup routines and sometimes spilling more than their drinks, and here she was, analyzing their interaction and subsequently writing up notes to be turned into research papers, etc.

-

NIST draft SP 800-108 has been released.

SP 800-108

DRAFT Recommendation for Key Derivation Using Pseudorandom Functions

NIST announces the release of draft Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. This Recommendation specifies techniques for key derivation from a secret key using pseudorandom functions (PRF). Please submit comments to draft-SP800-108-comment@nist.gov with “Comments on SP800-108″ in the subject line. The comment period closes on June 28, 2008.

Yet more KDFs.

-

They just don’t quit, do they?

1

This is the first article analyzing the security of SHA-256 against fast collision search which considers the recent attacks by Wang et al. We show the limits of applying techniques known so far to SHA-256. Next we introduce a new type of perturbation vector which circumvents the identified limits. This new technique is then applied to the unmodified SHA-256. Exploiting the combination of Boolean functions and modular addition together with the newly developed technique allows us to derive collision-producing characteristics for step-reduced SHA-256, which was not possible before. Although our results do not threaten the security of SHA-256, we show that the low probability of a single local collision may give rise to a false sense of security.

2

We study the security of step-reduced but otherwise unmodified SHA-256. We show the first collision attacks on SHA-256 reduced to 23 and 24 steps with complexities $2^{18}$ and $2^{50}$, respectively. We give an example colliding message pair for 23-step SHA-256. The best previous, recently obtained result was a collision attack for up to 22 steps. Additionally, we show non-random behaviour of SHA-256 in the form of pseudo-near collisions for up to 31 steps, which is 6 more steps than the recently obtained non-random behaviour in the form of a semi-free start near-collision. Even though this represents a step forwards in terms of cryptanalytic techniques, the results do not threaten the security of applications using SHA-256.

3

[...]First we describe message modification techniques and use them to obtain an algorithm to generate message pairs which collide for the actual SHA-256 reduced to 18 steps. Our second contribution is to present differential paths for 19, 20, 21, 22 and 23 steps of SHA-256. We construct parity check equations in a novel way to find these characteristics. Further, the 19-step differential path presented here is constructed by using only 15 local collisions, as against the previously known 19-step near collision differential path which consists of interleaving of 23 local collisions. Our 19-step differential path can also be seen as a single local collision at the message word level. We use a linearized local collision in this work. These results do not cause any threat to the security of the SHA-256 hash function.

4

[...]We build on the work of Nikoli\’{c} and Biryukov and provide a generalized nonlinear local collision which accepts an arbitrary initial message difference. This local collision succeeds with probability 1. Using this local collision we present attacks against 18-step SHA-256 and 18-step SHA-512 with arbitrary initial difference. Both of these attacks succeed with probability 1. We then present special cases of our local collision and show two different differential paths for attacking 20-step SHA-256 and 20-step SHA-512. One of these paths is the same as presented by Nikoli\’{c} and Biryukov while the other one is a new differential path. Messages following both these differential paths can be found with probability 1. This improves on the previous result where the success probability of 20-step attack was 1/3. Finally, we present two differential paths for 21-step collisions for SHA-256 and SHA-512, one of which is a new path. The success probability of these paths for SHA-256 is roughly $2^{-15}$ and $2^{-17}$ which improves on the 21-step attack having probability $2^{-19}$ reported earlier. We show examples of message pairs following all the presented differential paths for up to 21-step collisions in SHA-256. We also show first real examples of colliding message pairs for up to 20-step reduced SHA-512.

Completely academic, but you know what they say - attacks only get better.

-

Interesting stuff.

NSA/CSS periodically releases declassified documents or indexes to these documents to the public. The documents listed on this page were located in response to numerous requests received by NSA on the various subjects stated and for which there appears to be a general public interest. The date after each entry reflects the most current release date of that material. When additional material for a given subject is updated then a new subject index date is posted. To select a subject index, click on the subject title.

In particular, the Cryptologic Spectrum Articles and Cryptologic Quarterly Articles have some fun reads.

-

An easy to cut ‘n paste into a blog post set of old web server log entries depicting an instance of Tor being used to proxy/anonymize automated probes of this web site.

anonymizer.blutmagie.de - - [13/Mar/2008:00:59:00 -0700] “GET /forum/phpbb/index.php HTTP/1.0″ 404 285 “http://forum.d-kriptik.com/phpbb/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymous.proxy.quex.org - - [13/Mar/2008:00:59:01 -0700] “GET /forum/phpbb2/index.php HTTP/1.0″ 404 286 “http://forum.d-kriptik.com/phpbb2/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymizer.ccc.de - - [13/Mar/2008:00:59:02 -0700] “GET /forum/forums/index.php HTTP/1.0″ 404 286 “http://forum.d-kriptik.com/forums/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymizer.ccc.de - - [13/Mar/2008:00:59:08 -0700] “GET /forum/board/index.php HTTP/1.0″ 404 285 “http://forum.d-kriptik.com/board/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

-

Like heat and humidity, free music and Central Park mean summer. The 2008 schedule is up at the Summer Stage web site. And, the opening Saturday looks good to me.

Vampire Weekend
Kid Sister
Ecstatic Sunshine

Saturday, June 14, 2008
From 4:00 PM to 7:30 PM
Central Park SummerStage

At some point, I saw this.

The 7.0-BETA1 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag.[...]

So, updating a few “play” systems here from FreeBSD 6.2 to FreeBSD 7.0 Beta 1 was pretty much a piece of cake.

I did something along this lines of…

• create a new custom kernel config (based on my old one)

  e.g.,
  cp /usr/src/sys/i386/conf/GENERIC /usr/mykernconf7
  vi /usr/mykernconf7 and modify as desired
  ln -s /usr/mykernconf7 /usr/src/sys/i386/conf/mykernconf7

• update /usr/stable-supfile to point to RELENG_7

  e.g.,
  vi /usr/stable-supfile and change to the relevant line to something like “*default release=cvs tag=RELENG_7″

• cd /usr/src
• cvsup -g -L 2 ../stable-supfile
• make buildworld
• make kernel KERNCONF=mykernconf7
• reboot (to single user mode)
• cd /usr/src
• mergemaster -p
• make installworld
• mergemaster
• reboot

…to upgrade the base OS.

With FreeBSD 7 Beta 1 running, I thought it would then be useful to rebuild all of my ports.

First, I updated my ports tree and grabbed the new index (for “make search” and “portupgrade” purposes).

• cd /usr/ports
• cvsup -g -L 2 ../ports-supfile
• make fetchindex

Next, I rebuilt ruby and then portupgrade. (Note: I generally perform a “make” by itself rather than just a “make deinstall” followed by a “make reinstall” so that I can verify the port does indeed build before removing the prior installation of the port.)

• cd /usr/ports/lang/ruby18
• make clean
• make
• make deinstall
• make reinstall
• make clean

When using a portupgrade configured with ruby-bdb to interface with the pkgdb.db, I then reinstalled ruby-bdb.

• cd /usr/ports/databases/ruby-bdb
• make clean; make
• make deinstall;make reinstall;make clean

Otherwise, portupgrade was still configured to use ruby-bdb1 to interface with the pkgdb.db, so I deinstalled ruby-bdb1. I did not reinstall ruby-bdb1 directly, as portupgrade would fail to reinstall if I had (when portupgrade is configured to use ruby-bdb1, it always attempts to reinstall ruby-bdb1, even if ruby-bdb1 is already installed).

• cd /usr/ports/databases/ruby-bdb1
• make clean; make deinstall

And finally for portupgrade,

• cd /usr/ports/ports-mgmt/portupgrade
• make clean; make
• make deinstall;make reinstall;make clean
• pkgdb -F

Next, as is my normal practice when building ports, I looked in “/usr/ports/UPDATING” to see if there were any tricky port upgrades since my last update. Some places, I had Gnome installed, and it turned out that updating to Gnome 2.20.1 swapped in rarian for scrollkeeper, so I followed the steps in “/usr/ports/UPDATING”.

• portupgrade -f -o textproc/rarian textproc/scrollkeeper

Ok, that being the only trickiness since my last port update, I proceeded to rebuild every installed port.

• portupgrade -fa

Yes, that took quite a while.

After using the functionality of this machine I normally use and running stably for a bit, I cleaned up my ports.

• portsclean -CDL

So, the system seems to be stable, although I have not done anything that punishes it as yet, beyond rebuilding all the ports.

A few notes, not necessarily FreeBSD 7 related:

1. Running “ndisgen” under FreeBSD 7 had trouble on a driver where it had worked fine under FreeBSD 6. When I used an interactive run of ndisgen where the inf and sys file names were entered when prompted, the ko generation failed. However, when I entered the inf and sys file names as commandline options worked, the ko generation succeeded, and the resulting kernel module worked fine.)
2. Portupgrade was changed to use ruby-bdb by default a while ago. If you are still using ruby-bdb1, now might be the time to switch to ruby-bdb. This is somewhat trivial to do, and the following will rebuild portupgrade and its database for ruby-bdb.
   • cd /usr/ports/ports-mgmt/portupgrade
   • make config
     (select the ruby-bdb option and deselect the ruby-bdb1 option)
   • make clean; make
   • make deinstall; make reinstall
   • cp /var/db/pkg/pkgdb.db /var/db/pkgdb/pkgdb.db.bdb1
   • pkgdb -fu

   The following updates the ports index database. For FreeBSD 7, this is “/usr/ports/INDEX-7.db”, which is used below.

   • cd /usr/ports
   • mv INDEX-7.db INDEX-7.db.bdb1
   • portsdb -u
     or,
     portsdb -Fu
     if you do not already have an up to date ports index.

3. If you find, at the end of a “portupgrade -fa” run, that some ports failed to be rebuilt, it can be quite annoying.

   If this list of failed ports is quite large, often it is due to a few key ports failing to build, and then all ports dependent on those key ports being skipped. By fixing whatever issues arose with those key ports during building and getting them to build, you can then get all the skipped ports to build.

   After fixing all key ports, you could then use portupgrade to rebuild all ports dependent on those key ports (e.g., “portupgrade -r <port name>”); however, this can be painful if a number of key ports failed, especially with layered dependencies (e.g., one failed port causes another port to be skipped, but this skipped port is a dependency of another port causing that other port to be skipped, and so on). This is especially so given a “portupgrade -fa” on a large base of installed ports. So, I found it much easier to just rebuild all ports not installed after a particular date, with the particular date being the day before I began the original “portupgrade -fa”.

   For example, say we began out “portupgrade -fa” on October 30, 2007. It wrapped up, and we found a few ports failed to build successfully and a bunch of other ports were skipped because of this. So, we go in a fix the few ports that failed causing the other ports to be skipped. After that, we can run something like the following to rebuild all ports installed prior to October 30, 2007, which would map to all the ports that failed during our “portupgrade -fa” started on 2007-10-30.

   • portupgrade -f ‘<2007-10-30′

I made it out to the NYCBUG meeting this month. The following is my raw notes from the meeting.

First off, I must say this meeting was full of optimism for the current boom in technology. And, BSD jobs seem to be quite common these days - OKCupid and Fotolog both announced the need for some strong BSD people during the meeting. (You might want to start shopping that resume.)

So, the point of this meeting and possible future meetings is to try to capture the dynamic of the NYCBUG talk mailing list in a face to face meeting. If you have not hit upon the NYCBUG talk mailing list before, it is basically a place where people can post questions, issues, and everything else BSD related and get informative and friendly feedback from others in the BSD community, including many well known names. (I note that “newbie” questions are not mocked on this list, which is quite rare in technical forums.)

Anyway, on to the content…

—

The meeting started out with a discussion from Bjorn about things he misses from FreeBSD when using GNU/Linux at work. These essentially boiled down to the ease of getting various statistics off the system.

For example,

• “netstat -w 1″ versus “sar -n DEV” - no history

  (someone suggested trying “iptraf”)

• “iostat 1″ versus the GNU/Linux version - no history
• “vmstat” versus Linux version - less info
• “ifconfig” versus Linux version - less info

  (someone suggested “mii-tool”)

Bjorn also discussed some configuration and logging features he misses. (These reminded me of when I first picked up FreeBSD again, which seemed much more GNU/Linux in configuration layout after I had been using OpenBSD for quite a while.)

-

(Interesting note, Theo apparently insulted the dmesgd feature of the NYCBUG web site because it was a webapp and he did not like webapps.)

-

Next up, Alfred Perlstein spoke about the infrastructure at OKCupid, which is a free online dating services. (I thought I had never heard of OKCupid, until he mentioned that they have all sorts of questionaires - then I remembered being sent a link to a political questionaire a while back that ended up telling me I was something along the lines of strongly libertarian. Sure enough, looking in my archives, it was OKCupid.)

Alfred started out by saying OKCupid is looking for some BSD people. If you are interested, send him your resume via email - being at the NYCBUG meeting earns extra credit.

OKCupid runs a 99% FreeBSD shop. They were running a flavor of 4 for a while, tried 5 and found it to be garbage (like every other FreeBSDer it seems - I never used FreeBSD 5 myself), and now are running 6 (6.1 currently).

OKCupid is built from mostly open source technology. Even their custom web server, OKWS created by Max Krohn, has been released to the public under GPL.

(Of note, Max Krohn is of fake CS paper fame.)

Apparently, there is some lore about just how much performance OKCupid squeezes out of their systems, so someone asked Alfred about it. Alfred said one of the keys here was a custom distributed memory cache, DSDc created by Krohn. He then went on to discuss their architecture at a very high, non-proprietary level, and it looked something like this.

(A fuller discussion of web service architectures built from OKWS can be found in papers [1, 2] by Krohn.)

The ability to build services for the OKWS framework is based upon SFS, which uses event-driven callbacks at its core and no threads. The tame framework is used to provide thread-like features such as blocking, but it should be noted that actual threads are not used in SFS.

Alfred also noted that they use “sup” to handle upgrades and installs for their systems.

OkCupid itself is free to use. It is ad and donation supported. (Give it a try - I may.)

-

After that, there was a question about active directory and samba integration. I did not actually catch the outcome of the discussion.

—

Audio of the meeting can be found here.

As for comments on the open format, I thought this meeting went well. Meetings need to have some structure, including an agenda and a leader. That happened. There should always be at least a couple of people that will be presentating some BSD topic of interest or concern to them, and these people should be prepared/able to speak on that topic - maybe not as formally as a normal meeting, but definitely showing they thought about what they is being presented or strong enough that they can wing it effectively. That happened. This could be followed by some general discussion that flows into after meeting bar talk. That also appeared to happen.

My main concern is that the open meetings could easily degenerate into an hour and a half of random questions better suited to the talk mailing list. The good thing about the talk list is that there is effective administration and most people formalize their questions/concerns a bit just to put them into a decent email message to the list - I think that type of effort needs to be translated into the open meeting as well.

Thanks to the NYCBUG team and all the speakers.

(Oh, and apologies to my “date” - I did not expect the meeting to last the full amount of time scheduled.)

——

In other (sorta BSD) news, this sounds like a DoS attack to me.

If I closed the GPS.dix.dk server right now, wrote off all the time I have spent myself, then my expenses would amount to between DKR 45.000,00 and DKR 99.000,00 (USD 7,300 to 16,000) and several hundered administrators throughout Denmark would have to spend time reconfiguring their servers.

If on the other hand we assume I leave the service running and that the unauthorized packets from D-Link products continue for the next five years, the total cost for me will be around DKR 115.000,00 + 54.000,00 per year (approx USD 18,500 + USD 8,800 per year) or DKR 385.000,00 over the next five years (USD 62,000).

I was recently asked via email whether using a constant, hard-coded salt with the traditional Unix crypt function was a bad idea. I sent off a quick reply to point the person in the right direction, but I figured it would be good to write a quick blog post as well. (The small link farm at the end is the most useful part of this post.)

In general, this is a bad idea. The point of mixing in a salt as part of generating password hashes with the crypt function is so that the same password does not necessarily generate the same password hash. The set of possible password hashes that can be selected by the crypt function for a particular password grows expontentially with size of the salt (the salt is 12 bits here, so 2^12 password hashes are possible for each password). This can make precomputing password hashes and building lookup tables more difficult as such efforts will have to incorporate the unknown salts and thus the larger set of password hashes possible per password, and this can increase the effort of cracking multiple password hashes as the same salt needs to be shared between password hashes for the work performed on cracking one password hash to be easily applied to others.

For example, say I generate password hashes by running a password through SHA-256. Now, say I have a 48 bit salt that is randomly generated and appended to the password before it is run through SHA-256 to generate the password hash. For any given password, there are now 2^48 different password hashes possible, instead of the just one if I did not use a salt. If an attacker wanted to precompute hash values for a dictionary, that means each dictionary entry will require 2^48 password hashes instead of just one. If the attacker gained access to multiple password hashes, the effort of cracking one of those password hashes only applies to another password hash if their salts (a one in 2^24 chance in the ideal world, is it?) are the same instead of applying to all passwords hashes when no salt is used.

(One thing to keep in mind here, the salt is not being used to notably effect the speed with which the crypt function computes password hashes, which is sometimes implied in discussions on this topic. In fact, the traditional Unix crypt function and even the MD5 crypt function both take a constant, non-configurable amount of computation to generate password hashes. Also, the salt used for generating a particular password hash is assumed to be public - it is not a secret like the password - so the effort of attacking an individual password hash is not made any harder by using a salt.)

Ok, so, by using a hard-coded, constant salt, the same password will generate the same password hash. If this constant salt becomes public and thus attackers can be assumed to know it, then really all benefit of using the salt is lost - it can just be considered (a slight variant of) the traditional Unix crypt with no salt.

That is not to say that this change cannot be used without some security benefit over the usual crypt function without a salt - if this constant is configurable, then it can make precomputation more difficult following similar, but weaker, logic as for a salt. And, if this constant is kept secret, then there is effectively additional “key material” being used to generate the password hash, which makes precomputation more difficult and could even make it harder to crack individual password hashes. But then, using the term salt becomes misleading - perhaps it should just be called the “concatenated constant.” (I don’t know about everyone else, but assuming password hashes can be accessed but not the “concatenated constant” seems a bit strange to me.)

Even with salts, the traditional Unix crypt function is quite dated and may not be a good choice for generating password hashes. The tiny salts, short password length, optimizations, current processing speeds, etc. all combine to make crypt function generated password hashes quite susceptible to password cracking efforts. The two common alternatives are the MD5 crypt function, which uses the MD5 hash algorithm as its underlying crypto primitive and incorporates a salt, and the blowfish crypt function, which uses the blowfish encryption algorithm with modified key schedule as its underlying primitive and incorporates both a salt and an interation count. The blowfish crypt function is considered to be the latest and greatest crypt function that is widely deployed.

(FYI, there was recently a discussion on the NYCBUG talk mailing list about the fact FreeBSD still ships with MD5 crypt function as the default. Instructions for configuring the default crypt function settings in FreeBSD can be found here.)

A few good papers on the subject… the Unix crypt paper from back in 1979 (and 10 years later) and the OpenBSD bcrypt design paper from 1999. A good interview on the topic… Solar Designer’s (author of John The Ripper) interview from earlier this year (2006). PKCS#5 might be of interest as well. (There was also this paper in the aforementioned CCS 2005 proceedings.)

(Of course, the key here - see Appendix A - is choosing good passwords. This blog commented on passwords way back when the blog first started.)

So, I went to install GnuCash on a machine running FreeBSD 6.1 Prerelease (”cd /usr/ports/finance/gnucash; sudo make install”) a couple of days back (19-03-2006). Just as I was rejoicing at all the dependencies being handled automatically (and goodness knows there were many), the install died.

===> gnucash-1.8.12_1 depends on executable: gmake - found
===> gnucash-1.8.12_1 depends on file: /usr/local/bin/perl5.8.8 - found
===> gnucash-1.8.12_1 depends on file: /usr/local/bin/intltool-extract - found
===> gnucash-1.8.12_1 depends on executable: pkg-config - found
===> gnucash-1.8.12_1 depends on shared library: guile.15 - found
===> gnucash-1.8.12_1 depends on shared library: guppi.16 - found
===> gnucash-1.8.12_1 depends on shared library: popt.0 - found
===> gnucash-1.8.12_1 depends on shared library: ofx.2 - found
===> gnucash-1.8.12_1 depends on shared library: gw-standard.0 - not found
===> Verifying install for gw-standard.0 in /usr/ports/devel/g-wrap
===> g-wrap-1.3.4_8 depends on file: /usr/local/share/guile/slibcat - not found
===> Verifying install for /usr/local/share/guile/slibcat in /usr/ports/lang/slib-guile
===> slib-guile-3a1 is marked as broken: Does not install.
*** Error code 1

Stop in /usr/ports/lang/slib-guile.
*** Error code 1

Stop in /usr/ports/devel/g-wrap.
*** Error code 1

Stop in /usr/ports/finance/gnucash.

Sure enough, the makefile (”/usr/ports/lang/slib-guile/Makefile”) for slib-guile in the ports tree identified the port as BROKEN.

BROKEN= Does not install

A quick search of the FreeBSD ports mailing list archives, and there was a recent post pointing to the following workaround.

1) Use portdowngrade to grab the slib-3a1_2 version, and install it.
gnucash/guile does not like 3a3.
2) Use pkgtools.conf to ‘hold’ slib-*.
3) remove the “BROKEN” status from slib-guile-3a1

Attempt ‘make install clean’ of gnucash.

(Note: The use of “sudo” proceeding these commands is not necessary if you are root, of course.)

I thought “slib-3a3″ was automatically installed as a dependency of GNUCash, but, before I removed it, I checked to make sure that was the case and there were no dependencies on “slib-3a3″.

• pkg_info -R slib-3a3

No packages were listed as depending on “slib-3a3,” so I removed it.

• sudo pkg_delete slib-3a3

I did not have “portdowngrade” installed, so I needed to install that.

• cd /usr/ports/sysutils/portdowngrade
• sudo make install

I tried using “portdowngrade” with SSH, but it fails as unsupported, which meant the USA anoncvs mirrors were out. I then tried the French anoncvs server, but this failed with some sort of read error for lang/slib. So, then I went to Japan.

• sudo portdowngrade -o -s:pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs lang/slib$

When prompted, I entered the password “anoncvs” (without quotes).

During step 3 of the 6 step process, a list of previous versions was provided, from which you could select one to downgrade to. I selected the number corresponding to “3a1_2″ (#3 when I was performing these steps), confirmed that I wanted to downgrade, and was downgraded.

As instructed by “portdowngrade,” I updated my ports database since I use “portupgrade” (this could have been performed later).

• sudo portsdb -Uu

With that completed, I installed the downgraded port, “slib-3a1_2″.

• cd /usr/ports/lang/slib
• sudo make install

I then edited “/usr/local/etc/pkgtools.conf” to hold “slib” and “slib-guile” by adding “slib-*” to the “HOLD_PKGS” array.

• sudo vi /usr/local/etc/pkgtools.conf

My HOLD_PKGS ending up looking as follows.

   HOLD_PKGS = [
     'bsdpan-*',
     'slib-*',
	]

I then edited the Makefile for “slib-guile” and commented out the “BROKEN= Does not install” line.

• sudo vi /usr/ports/lang/slib-guile/Makefile

With that all set, I was ready to build and install GNUCash.

• cd /usr/ports/finance/gnucash
• sudo make install clean

Perfect.

(Completely unrelated, this is quite interesting.

With new technologies constantly being invented in corporate and academic labs around the world, identifying which ones will transform computing, medicine, telecommunications and business always is a challenge. In “10 Emerging Technologies,” a special package in the March/April issue of Technology Review, MIT’s magazine of technology, the editors name those that they feel will soon have a significant impact. The ten technologies are also featured at www.technologyreview.com/special/emerging.

via Infectious Greed)

So, I had what was supposed to be an informal meeting with a small business to discuss how to go about upgrading their current infrastructure to support their growth from 3 people to a planned 10 people over the course of this year. We were originally going to meet in a bar, but ended up in a conference room, where I briefly presented about what I have experienced during such a transition and then was interrogated for quite a while.

After this meeting, I was on my way to the NYCBUG meeting, when I remembered the meetings had been changed from 6:00PM EST to 6:30PM, so, being in the area of Heathers, I popped in for a drink. Heather soon came in, and she mentioned that she used to do some tech support for Macs. We discussed that I may need more Mac people in the future, and, while she was not directly interested in such a role, she knew people who would be. Good to know.

Unfortunately, the next thing I knew, it was after 6:30PM, so I dashed out of Heathers and ran up to Baruch college on E 25th. By the time I made my way to the proper room (through two security checkpoints), it was the question and answer (QnA) portion of Ray Lai’s presentation on systrace. I was disappointed to only catch the last 15 minutes of his talk, as systrace is a good topic and its use is not as widespread as i’d expect in OpenBSD server environments.

My notes on the QnA follow.

-

There was a question about whether systrace has had any security issues itself, which made me chuckle a bit. Ray answered that it had on NetBSD (not OpenBSD), the last one that he knew of discovered back in 2004 (a quite simple local exploit).

There was some discussion about using systrace to debug applications, which I had never really thought of explicitly in those terms before and so had me mumbling to myself a little in thought. For example, whenever an application crashes because systrace limited its access, well, you then go about debugging what access that application thinks it needs and why. I think the gist was taking the concept of that example and using it to learn about limiting an application’s privileges during development and testing.

Johnny Lam chimed in about using systrace to lockdown builds. When you download the source code for some rogue application and build it, you really don’t know what is going to happen during that build process. Since building generally requires a very limited set of permissions, it is easy to run the build in systrace with a very strict policy and note any weird access attempts. (I have really enjoyed hearing Johnny Lam discuss his NetBSD development environment, from encrypted file-backed domains in Xen with keys stored on a token to builds conducted using systrace.)

Ray noted that the OpenBSD ports have the option to use systrace during builds, although this option is not enabled by default (set the “USE_SYSTRACE” variable to “Yes”).

There was some discussion about systrace being easier to implement in server environments, where the services provided are normally well-defined and quite limited, versus a desktop environment, where there is a wide variety of software that a user may wish to run and covering all of it with systrace can be a huge, complicated task.

Systrace is part of base on both NetBSD and OpenBSD.

-

The presentation slides are available online here, and an audio recording of the presentation can be found here. (I am listening to it right now.)

Thanks to Ray Lai for presenting and NYCBUG for its continued efforts.

Systrace at the next NYCBUG meeting. (The systrace chapter from “Secure Architectures with OpenBSD” is freely available here.)

March 01, 2006
Ray Lai: Systrace for Slackers

NEW Time & Location!
And it is necessary to RSVP

Please send an email to rsvp at lists dot nycbug dot org with `RSVP` and your full name in the subject line

6:30 pm, Baruch College, CUNY
Building H, Room 620
E 25th Street between 3rd Ave & Lexington
Map

Systrace is a facility to confine programs to doing what they are supposed to do. When do they do “bad” things? When they get exploited, of course!

Most people either never heard of Systrace or don`t know how to use it. I hope to change both these problems.

Fortunately, the NYCBUG team found a temporary location for the NYCBUG meetings, which will be used for the March and April meetings. There is this though.

IMPORTANT: It is compulsory to RSVP for this meeting. . . so you MUST do
the following:

EMail to rsvp at lists.nycbug.org with the subject line of:

RSVP FirstName LastName

The cutoff time for the RSVP is 3 pm on Wednesday. You only need to
RSVP once for either or both meetings. Obviously, if you’re not sure
whether you’ll be attending the meetings or not, RSVP anyway.

Also, make sure you have an ID with you.

I have to grab a beer with a prospective client early in the evening, but I will run over to this meeting afterward. Hopefully, I will not be too late.

Also, the next dorkbot-nyc meeting is taking place the same night.

The nine million and twenty ninth dorkbot-nyc meeting will take place on Wednesday, March 1st at 7pm at Location One in SoHo.

Featuring,

• almost certified by k.cain and b.crabtree - “almost certified (grade A noise for non-discerning consumers) is a mechanical sound installation and informative publication. a distributed network of precarious egg-tapping robots.”
• Whorld by Chris Korda - “Whorld is a free, open-source Windows program that offers a unique approach to creating live digital art. Whorld generates real-time animation, but unlike most visualizers, it’s designed for performing, and includes MIDI support and other features more commonly found in clip-based VJ programs.”
• Heddatron by the botmatrix - “For the past year and a half The Botmatrix collaborated with The Les Freres Corbusier theater company on their latest play Heddatron: An adaptation of Henrik Ibsen’s classic play Hedda Gabler complete with 5 robots.”

Unfortunately, I will most likely not make it to this dorkbot-nyc meeting due to the NYCBUG meeting being held in east midtown for the time being. If anyone else is planning to attend and wants to do a brief write-up, please let me know.

Both events are always a good time, and you will meet some cool people. Check them out.

My mobile phones are mainly turned off these days because they are old, their batteries barely last a day, and I have other means of receiving calls/messages. Plus, the selling of cell phone records and the tracking capabilities do not make me smile. Nevertheless, once a certain line of phones is updated by my provider, I will upgrade and use mobile phones a bit more again - a consumer to the bone.

Anyway, we all know cell phones can be used to track us. Well, here is another example of that.

On the website, I see the familiar number in my list of “GSM devices” and I click “locate”. A map appears of the area in which we live, with a person-shaped blob in the middle, roughly 100 yards from our home. The phone doesn’t go off at all. There is no trace of what I’m doing on her phone.

If you care enough, it has long been time to turn off that cell phone, or just leave it at home (locked in a safe ).

via cypherpunks

-

NIST has published a draft “Guidelines for Media Sanitization” for public comment.

When storage media are transferred, become obsolete, or are no longer usable or required by an information system, it is important to ensure that residual magnetic, optical, or electrical representation of data that has been deleted is not easily recoverable. Sanitization refers to the general process of removing data from storage media, such that there is reasonable assurance, in proportion to the confidentiality of the data, that the data may not be retrieved and reconstructed.

This guide will assist organizations and system owners in making practical sanitization decisions based on the level of confidentiality of their information. It does not, and cannot, specifically address all known types of media; however, the described sanitization decision process can be applied universally.

Basically, destruction is best, but overwriting may be satisfactory, depending on one’s needs. Of course, the ideal is to never let sensitive data hit the storage media in plaintext, if it has to hit storage media at all. (Still, RAM and what have you will touch plaintext data and keys.)

Peter Gutmann published the classic paper on wiping data from magnetic storage and solid-state media (I normally refer to this as Gutmann grade wipes - 1-4 pass wipes using random data, or 35 pass wipes using particular patterns and random data for those that like security theater on today’s storage media), and his follow-up covering semiconductor devices. The DOD has published techniques for wiping media (I normally refer to this as military grade wipes - 1 or 3 pass wipes using a single character, or a single charater, its complement, and random data).

via Rootsecure.net

-

bsdtalk has been flying through podcasts with popular figures in the BSD community.

-

[here i stopped reading] had me rolling with laughter. Perhaps Ptacek didn’t get the memo - everyone is stoopid that does not use Linux[here i ran out of sarcasm]

-

In case you didn’t know, models eat.

Someone I know pointed this article out to me.

Instead, the past two years has seen a proliferation of smaller companies building Web-based applications, sometimes referred to as Web 2.0, as well as open-source companies. Many of these firms can get off the ground with relatively small up-front investments, not the tens of millions of dollars that venture capitalists pumped into new software ventures in years past.

Web 2.0 bubbles aside, this brought to mind an old post here, in reference to businesses catering to small businesses and home users.

Selling software is so last century, much like long distance call fees. New software is distributed for free virtually immediately after its development, regardless of a company’s desire to sell it, and we could chat about ways to control that, but I don’t think there is much point in that. Services are what matter now. A company could build custom software into your architecture and then provides services to clients through this infrastructure. Or, a company could give away their software, perhaps even open source it, and then support customers in using it - build a custom architecture for clients out of it, add specific features requested by customers, support customer developers in modifying it, etc. You know, services.

All of this reminded me of a discussion I had over the holidays with a CTO of a medium-sized business. I talked briefly about my business, and my belief that free software was the future for small businesses and home users, and that businesses would sell services, not software, to support small businesses and home users.

This opinion did not go over well at first, and I am not sure why as there was no explanation. However, the concept gained momentum as the day turned to evening, and the rain picked up. (My opinions are well known, so I will just briefly note some of his thoughts.)

There was some discussion about usability improving in many open source projects, and he said that he could see the big boy distributors like Dell saving on costs by removing expensive software licensing requirements and switching to open source in the future.

We discussed how each of our mothers use their computers, and he made the general point that, given Firefox and Thunderbird running on a Debian derivative GNU/Linux distro with a windows manager like KDE (I said Gnome), and they would be all set. (Of course, as things stand now, this would have to be pre-configured to just work, which may not be trivial, but after that, their normal use would be covered. Sure, they would need our help from time to time, but that is no different from Windows XP.)

Most interesting of all and on the small business side of things, we talked about backend servers. He works at a medium-sized business, and they use information technology quite robustly. In this groove, he discussed their choice of Solaris as a rock solid platform a few years ago, but they have now switched to Enterprise Redhat, which they have found to be just as reliable, fully supported by RedHat, and a fraction of the cost of Solaris. (I am partial to BSD flavors myself, and FreeBSD would have been my choice here based on what he told me about their architecture.)

And, that brings us back to the article that began this post.

Freely available open-source software is becoming increasingly robust and powerful hardware servers are relatively cheap. Five years ago, start-ups would have had to spend tens or hundreds of thousands of dollars for equivalent products.

—

Totally unrelated…

A paper providing a security proof for what was already generally accepted.

HMAC (Bellare, Canetti and Krawczyk, 1996) is a cryptographic-hash-function-based MAC that is widely used both as a MAC and as a PRF. To prove it secure as a PRF, BCK96 assumed both that the compression function was a PRF and that the hash function was weakly collision resistant. In this paper we show that the second assumption is unnecessary, proving the construct is a PRF (and hence a MAC) under the sole assumption that the compression function is a PRF. This helps explain the strength that HMAC has shown even when implemented with hash functions like MD5 and SHA-1 whose weak collision resistance is (fully in the first case and partially in the second) compromised by known attacks. (Known attacks do not compromise the compression functions as PRFs.)

Also, I note the following paper because it is by the designers of AES. The results are purely academic and meaningless to someone like me.

In this paper we study the probability of differentials and characteristics over 2 rounds of the AES with the objective to understand how the components of the AES round transformation interact. We extend and correct the analysis of the differential properties of the multiplicative inverse in GF($2^n$). We show that AES has characteristics with a fixed-key probability that is many times larger than the EDP.

I made my way over to the NYCBUG meeting a few days ago, which was a talk by Johnny Lam on using Xen with NetBSD.

The meeting started out with administrative announcements. The next NYCBUG meeting will be held somewhere else, as the Apple store is about to undergo some rennovations, but where has yet to be determined. NYCBUG has a TOR node, and Roger Dingledine should be speaking at an upcoming meeting about TOR, which is a talking I am really looking forward to hearing. This was the 2nd anniversary of the NYCBUG public meetings. The NYCBUG web site has been redone, and there are some cool new features, such as submitting port requests. There were also requests for other people to present material at BUG meetings. (I’d love to give a presentation, so hopefully a topic will come to my mind that merges my focuses with subject matter relevant to these meetings. As it stands, the majority of my contribution has been meeting attendance and a couple of glossy posts to the NYCBUG mailing lists. Given TOR is going to be a topic, perhaps the gap is not as wide as I thought.)

After this administrative stuff, Johnny Lam arrived and spoke about Xen. He seemed quite used to public speaking, which is not always the case at NYCBUG meeting (the meetings often serve as a practice forum).

The beginning of the talk was just high level discussion about why to use virtualization at all. The main use is to effectively isolate users and processes, which Unix alone should accomplish by design, but which is often quite hard to accomplish in practice. Johnny discussed the two sides of the spectrum in accomplishing this isolation, and then he discussed virtualization as part of the middle between those extremes. On the one extreme, all servers have their own physical machines. So, the FTP server would be on a separate physical machine from the web server, etc., and so forth and so on. On the other extreme, all servers would be on one machine, and the operating system would be relied upon to keep separation between them all. So, the FTP daemon would be kept separate from the web daemon by process separation, permissioning, etc., and so forth and so on. Virtual machines sort of merge these two extremes, allowing for multiple, logical machines to be running on one physical machine. In theory, each virtual machine is distinct from the other virtual machines and can be viewed as its own machine (although how true that is in practice is a question in my mind).

Johnny went on to talk briefly about Xen and his particular setup. He talked about the privileged domain (domain 0 - think root) and the guest (unprivileged) domains (domain U - think everyone else). Domain 0 essentially serves to manage the guest domains, so Johnny runs only the bare minimum needed to do this in domain 0. The guest domains run everything else.

What really caught my attention though was the usage of file-backed guest domains using encrypted (CGD) virtual disks (VND) (pardon my attempt at NetBSD terminology). Domain 0 would setup the encrypted virtual disks and then configure the guest domains to use them. The setup reminded me of my post about using encrypted memory disks in FreeBSD, as this would be a really cool way to use encrypted memory disks. Take those encrypted memory disks and use them for your virtual machines, which could mean that everything that machine tries to write to disk is encrypted first, but without the fanagling necessary to try to setup FreeBSD with boot/root encrypted. Combine that with encrypted swap for domain 0, and perhaps all the bases are covered. Cool stuff.

That is about it for my notes. Slides can be found here, and audio of the presentation can be found here. Put the two together, and there you go.

Thanks to Johnny for a good talk and to the efforts of NYCBUG.

-

On a related note, I stumbled across the following.

First off, I found this blog, which seems to keep up with lots of virtualization news, and in it was this post. So, it looks like more than a player is going to be out there for free by VMWare. Cool.

An email circulating in these hours reports GSX Server is going to change name in VMware Server, distributed for free from 6th February.

Second, I found this site via that blog, which discusses the efforts to port Xen to FreeBSD. (I am excited about this, as jails seem more like glorified chroots than full blown virtual machines, unless I am missing something.)

This page is intended to document the work on FreeBSD on Xen and the sun4v hypervisor.

No domain 0 yet, but it is coming.

-

Totally unrelated, I have heard Berlin’s The Metro mixed seamlessly in quite a few DJ sets recently. That icy track is as cool today as it was in 1982. Who would have imagined transitions like Bloc Party’s Banquet to Berlin’s The Metro back 20 odd years ago when the latter came out? It reminds me of UFS or the unix epoch.

Oh, and a brief post on the last dorkbot-nyc meeting is forthcoming.