May 18, 2003

So who the heck do you tell?

I'm in what seems to be an odd situation. Well, odd for me at least.

I'm getting peppered with virus mail. Now, this isn't at all unusual--I get a lot of virus generated mail. Goes in waves, of course, but it's not too unusual for me to get 30-40 a day, with a normal day being more like 10-20. SpamAssassin catches almost all of them, so they just sit in my SPAM folder on the server waiting for me to pop over and clean 'em out along with all the other dreck that gets pounded my way.

SpamAssassin, along with Vipul's Razor, seems pretty darned good at catching these things, so I generally don't pay them any mind. (I'm also running Eudora on OS X, so it's not like I'm vulnerable to these damn things anyway) Today, though, three got through in relatively rapid succession, all with a spoofed "from" of "support@microsoft.com", and all from the Netherlands (according to the headers). That was unusual enough that I decided to pop over to both MessageLabs and Symantec's website and see which one it is. As far as I can tell, no joy. Nothing matches the characteristics of this thing.

The sensible thing to do, once a check of the search databases and a strings on the decoded attachment turns up nothing, is to report it to the AV folks, right? I mean, my e-mail address has been plastered all over everywhere for more than a decade (yes, dan at sidhe dot org has been active since April 1993), I haven't made any real attempts to spoof my address anywhere, and I generate far too much e-mail, so it doesn't seem too arrogant to assume that on occasion I'll be one of the first people pinged by a new virus. I wouldn't expect it to be a common thing, but neither does it seem unlikely enough to discount.

Given that, I go searching for an e-mail address to submit the message to. A quick pine bounce should send it on, headers and payload intact. Or it would, if I could find where to send the damn thing. A search of the MessageLabs website turns up nothing. (Matt Sergeant, who's active in the perl community, works there, so I figured I'd try them first) A search of the Symantec website also turns up nothing. I could ping some people I know directly, but... I don't think so. Seems an inappropriate use of personal e-mail addresses, and besides, by the time they get it and deal with it likely they'll know by some other mechanism.

Still, it'd be nice to have some way to know. Know that it is, in fact, a known virus, or is something new, and if it's new know that someone'll deal with the damn thing. The sooner the better since, while I'm not vulnerable, I still have to deal with the fallout of a zillion virus messages. Bleah.

Update: On the off-chance someone actually wants a copy, I did a save to a new mailbox in pine and put the results here. Complete with internal folder bits, but chop those off and it's there, in all its glory. SpamAssassin has processed it, hence its headers. I don't have a fully unprocessed version.

Update 2: Well, it turns out not to matter. Whatever this thing is, it's wide-spread. As of 7:30AM EST today, I've gotten 131 of the damn things, and more to come I expect. Notifying anyone wouldn't have stopped that. And yes, I do now have a procmail recipe in to trash these on receipt

Update 3: Turns out to be the Palyh virus. Some day I'm going to sit down and figure out how much data got slung across my wires here just transporting virus traffic...

Posted by Dan at 06:14 PM | Comments (1) | TrackBack

API suckitude of the first order: Perl's magic from C code

So, I'm working on my slides for my "Writing Perl Extensions in C" class, which I'm giving at OSCON this year, and for the New York Perl Seminars group this month. (the evening of Tuesday May 20th, FWIW) Now, this isn't a big deal--I've been writing XS code for years, and it isn't that tough. Perl's API is primitive, dodgy in spots, and mostly undesigned, but it's not that big a deal, and no worse than other libraries I've had to use.

Since I really hate courseware that leaves off important details, I figured I'd better poke around in the docs a bit to refresh my memory about magic. Magic, in perl 5, is that stuff that lets you write code that intercepts read and write requests to a variable. It's used to implement tied hashes/arrays/scalars, lvalues returned from substr or vec, the %ENV hash, and a few other things.

Well...

This stuff is an absolute mess. Most of the API actively ignores magic, though not all of it. The docs for parts of the API says that it does handle magic is actually incorrect. And nowhere is it particularly well emphasized that you really do need to pay attention to magic. It's... well, it's bloody annoying is what it is. To write proper code you actually need to scatter a lot of SvGETMAGIC and SvSETMAGIC calls thoughout it, to make sure that magic, if it exists on something, is properly triggered. Except when you don't, because they happen implicitly. And in those cases where you know no magic is involved.

It doesn't help that the docs are horribly scarce here, and not even the one mostly definitive work on the subject (Extending and Embedding Perl by Jenness and Cozens) doesn't touch on magic at all. I'm currently not sure what the right thing is, nor how many modules on CPAN get it right through sheer happenstance or good choice of defaults by perl. That makes me... nervous.

It's enough to tempt you to add little "This is somewhat more complex with magic" footnotes all around. Or rewrite it entirely. And since I'm doing the latter, I might do the former too. Unfortunately there's no time to do the proper research for the first runthrough, and possibly not in time for the materials turnin for OSCON, so there may well be good reason to take notes in class...

Posted by Dan at 04:11 PM | Comments (1) | TrackBack