The Troll-Range » Windows

XHTML 1.1

Ghworg — Sun, 19 Feb 2006 14:25:05 +0000

I’ve recently made my site xhtml 1.1 compliant, even serving it as application/xhtml+xml to those browsers that say they support it. The changes I’ve made have messed up the layout for Internet Explorer I’m told. I don’t have a copy of IE on hand right now to check and all the decent browsers show the site properly so if you are having problems I suggest you go get firefox.

I may or may not get round to fixing things so it lays out properly in IE at some point. Hopefully IE7 will come out soon and be standards compliant enough that I won’t have to bother .

(Update: I’ve backed out the application/xhtml+xml header change since there is at least one page that doesn’t validate. Silly me didn’t think to check anything other than the main page).

WMF flaw was deliberate

Ghworg — Sat, 14 Jan 2006 16:03:28 +0000

Wow, this is really scary. I just listened to episode 22 of the SecurityNow podcast and according to Steve Gibson the recent WMF vulnerability on windows may have been a backdoor intentionally placed there by Microsoft. The nature of the flaw means that there is absolutely no reason for it to be there as a feature as was previously assumed. While a coding flaw is always possible it’s extremely unlikely in this case as it’s not something you could just overlook like a buffer overflow. Not only that but this code must have been reviewed several times by Microsoft’s security team when other WMF flaws surfaced previously. So either they are a bunch of morons and missed it or they already knew about it and left it in there on purpose. Eep!

If this is really true then it makes you wonder how many more backdoors there are in there and what Microsoft intend to do with them.

Setting up cygwin sshd

Ghworg — Fri, 18 Feb 2005 08:39:49 +0000

I couldn’t manage to get public key authentication to work for the cygwin ssh server. It just kept rejecting my key for no apparant reason, the permissions on all the files were correct and the server itself was configured fine. The problem turned out to be windows permissions.

Failure output:

Connection from $IP port 36230
debug1: Client protocol version 2.0; client software version OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INI
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user user service ssh-connection method none
debug1: attempt 0 failures 0
Failed none for user from $IP port 36230 ssh2
debug1: userauth-request for user user service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: n/n (e=n/n)
debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: restore_uid: (unprivileged)
debug1: temporarily_use_uid: n/n (e=n/n)
debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: restore_uid: (unprivileged)
Failed publickey for user from $IP port 36230 ssh2

Fix:

setfacl -m u:system:r– ~ ~/.ssh ~/.ssh/authorized_keys

found here.