Saturday, August 30, 2003

Sony Style Warning needs a Warning?

Within the past month or so, I received a warning from Sony about fraudulent e-mails claiming to be from Sony but that actually were not. The deceptive e-mails were designed to lure Sony customers into divulging personal information at a fake Sony site. It "falsely indicates that it is from SonyStyle.com" and "includes a link to a bogus SonyStyle.com registration site"

So, I was shocked to notice that the e-mail from Sony that was supposedly warning about deceptive e-mails and URLs was itself guilty of using apparently deceptive or "fraudulent" URLs!

Within the text, it contained a couple of URLs that, in the HTML version of the e-mail, deceptively show up as www.sonystyle.com, but in fact pointed to some other site at m0.net. Here is one of the deceptive URLs from Sony:

http://news.sonystyle.m0.net/m/S.asp?HB9483736521X2571692X218821X

Not to mention that the From address of the e-mail was also from the same site: [email protected]

Should you trust the warning e-mail? Sure. The contents are benign enough. Just think twice about clicking those links or replying to the e-mail! Sony is surely using a company to send out the mass e-mailings and to track the "click-through" responses, but that seems like a pretty poor choice in this context!

Friday, August 29, 2003

Fox not "Fair & Balanced" in First Amendment treatment

This is such a great line.

In Courtroom, Laughter at Fox and a Victory for Al Franken


Judge Chin said the case was an easy one, and chided Fox for bringing its complaint to court. The judge said, "Of course, it is ironic that a media company that should be fighting for the First Amendment is trying to undermine it."


You can buy the book here:

Saturday, August 23, 2003

SPAM filter comparisons

SPAM is a truly egregious problem. This article does some analysis of popular spam filtering software. It is no surprise to me that signature-based programs tend to have slightly higher false positive rates and that Bayesian filters work best when trained properly, and have low or zero false positive rates.

I use bogofilter and have a corpus of thousands of spam messages that I have received, going back 6 or more years. It works great. I don't have to keep checking my spam bucket for false positives all the time and occasionally have to retrain if I get a false negative but online life is much better than before bogofilter. I was constantly having to scan through the spam bucket to pick out false positives.

freshmeat.net: Category Reviews - Spam Filters



Monday, August 18, 2003

OpenLDAP/OpenSSL stupidity

Sorry for not keeping up. Been enjoying the summer too much!

Anyhow, I thought that my experience in trying to get openLDAP 2.0.x working with TLS would be of interest to someone because the solution was so orthogonal it is unbelievable.

I have working OpenLDAP servers with TLS on two other machines so was baffled when I tried /etc/rc.d/init.d/ldap start and got [FAILED] with a very similar configuration to the others. Permissions on the TLS files are very finicky so I tried tweaking those--but nothing was working. I tried strace on the slapd binary but that did not offer any clues. I was able to get it to work by running slapd in debug mode on the command line, but in that mode it was ignoring the -u ldap so was running as root. So that told me there was some sort of permissions problem. But where?

Setting up syslog for openldap (not on by default, unfortunately) indicated these errors in the syslog logfile:

Aug 18 22:07:21 funhouse slapd[29220]: daemon: socket() failed errno=97 (Address family not supported by protocol)
Aug 18 22:07:21 funhouse slapd[29220]: daemon: socket() failed errno=97 (Address family not supported by protocol)
Aug 18 22:07:21 funhouse slapd[29220]: main: TLS init def ctx failed: 0
Aug 18 22:07:21 funhouse slapd[29220]: slapd stopped.
Aug 18 22:07:21 funhouse slapd[29220]: connections_destroy: nothing to destroy.

Hmmm. Not too helpful. I googled on these messages and didn't find a thing that helped. I tried all kinds of permissions tweaking to no avail.
Adding SLAPD_OPTIONS="-d 6" to /etc/sysconfig/ldap offered up these gems of wisdom:

TLS: could not load verify locations (file:`/etc/openldap/ssl/cert/cacert.pem',dir:`').
TLS: error:0200100D:system library:fopen:Permission denied bss_file.c:104
TLS: error:2006D002:BIO routines:BIO_new_file:system lib bss_file.c:106
TLS: error:0E064002:configuration file routines:CONF_load:system lib conf_lib.c:91
TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:662
TLS: error:0B084009:x509 certificate routines:X509_load_cert_crl_file:missing asn1 eos by_file.c:284
main: TLS init def ctx failed: 0
slapd shutdown: freeing system resources.
slapd stopped.
connections_destroy: nothing to destroy.
[FAILED]

WTF? So it looks like some permissions problem with /etc/openldap/ssl/cert/cacert.pem. But that file is world-readable. Does openLDAP think that it needs write perms to that file? Okay--wish granted. Nothing.
What finally turned me onto the final solution was the last line "X509_load_cert_crl_file..." The OpenSSL library is trying to find a CRL file. Why would it be having trouble (I don't have a CRL for my CA)? Poking around /usr/share/ssl I noticed that openssl.cnf is not world-readable. Well, I knew that. But most things that need it start as root and then drop privs and it hasn't been a problem. Let's just for the heck of it chmod 644 the file and try again.

# /etc/rc.d/init.d/ldap start
Starting slapd: [ OK ]

You have got to be kidding me?!?! openssl.cnf must be readable by the ldap user! None of the log messages indicated this. You would think that there would be an fopen() call that would fail in trying to open this file... Well, there is. Looking at the strace output I find:

open("/usr/share/ssl/openssl.cnf", O_RDONLY) = -1 EACCES (Permission denied)
getpid() = 11271
getpid() = 11271
getpid() = 11271
getpid() = 11271
open("/etc/openldap/ssl/cert/cacert.pem", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=3607, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
x40377000
read(7, "Certificate:\n Data:\n V"..., 4096) = 3607

The fact that openLDAP kept trucking along after failing to open what appears for it to be a critical file diverted attention away from the real reason it would not start!