Thursday, 14 May 2009

Ripped off by Mill Motors, Paisley

In January, I bought a used car from Mill Motors (4 Linwood Road, Paisley). The car had a serious fault which I reported to them within the 1 month guarantee period (confirmed by the official Saab dealership) and Mill Motors said (by phone) there was nothing wrong with it, that they were going to do nothing.

I thought I would be able to get some resolution to this since:
1) it specifically contravenes the sale of goods act
2) I paid for it on my credit card

So I've been chasing Mill Motors, Trading Standards and my Credit Card company for 4 months, trying to get some restitution. But Mill Motors refuse to put anything in writing - and as a result Trading Standards won't do anything, and neither will my credit card company.

grrr!

Lessons learnt:
1) never buy a used car from Mill Motors
2) if I ever get mugged, I'll be sure to get a receipt from the mugger for my credit card company.

Wednesday, 25 February 2009

More IIS oddities

hmmmm.

Script connecting to Oracle database worked fine in MSIE but fails in Firefox and Chrome.

On further investigation we discovered that the problem was due to PHP failing to open the tnsnames.ora file (this tells Oracle clients where on the network and what protocol to use when connecting to the database given in ora_logon / oci_connect).

Let's be quite clear here:
- when the request originated from MSIE, IIS had permissions to open the file
- when the request originated from any other browser, IIS did not have permission to open the file

In both cases, the script executes as the same user on IIS. Using a user-agent switcher on Firefox had no impact.

There is an additional complication that the file in question sat on a network share, but that should have no bearing on how IIS behaves. However using a local copy of the file works as expected.

Micorosft IIS's security model is working differently depending on the browser used - this is potentially a security vulnerability in IIS.

Again, Microsoft IIS is giving different and preferential treatment to MSIE browsers

Tuesday, 24 February 2009

OS war

At the weekend I was working on my home network. My daughter's new laptop arrived (a samsung R60, £300 @ dabs). This was my first prolonged experience with MS Vista.

I was first pleasantly surprised that it had rather sensibly split the disk into three partitions - one for diagnostics and TWO for Vista - a program drive and data drive! However Microsoft soon put a damper on my excitement - everything is so sssllllloooooowww. Just like previous versions of MS Windows, just about any change requires an immediate reboot - so just getting it working took about 3 hours and 6 reboots (Typically a Linux install from raw metal takes me 45 mins - although I only need to spend about 10 minutes at the computer and 1 reboot).

Then I got down to the business of configuring the software I really wanted. It came with a trial version of MS Office - Microsoft punished my insolence for removing the package by taking over an hour to uninstall it.

It also had SQL Server installed for some reason. That took just as long. And of curse Vista keeps asking me if I really do want to run xyz.exe at seemingly random intervals. How the hell should I know?

Still its just about done now.

Overall the laptop seems to be of good quality although the screen seems a bit washed out - not sure if thats just Vista's colour scheme though. When I've recovered from the pain of cleaning up the default install I'll add dual boot for something - probably PCLinuxOS 2008

Meanwhile, I rolled forward all the patches (only do the security ones on a regular basis) on my Fedora 9 desktop machine. This has taken away most of the rough edges in KDE 4.

Back at the office found a weird problem with PHP/Oracle/IIS - a script a colleague wrote to poll some data from Oracle works as planned if the browser is MSIE, but in Firefox it gives an ORA-12154 error (can't find database / tns names file). Very weird. Investigations continue.

Friday, 3 October 2008

Two factor authentication - grid Key followup

It looks like CAPCHA's days could be numbered. And not before time as I try to decipher the picture below the editor where I'm typing this.

Given such a simple idea as gridKey (working title - don't sue me) its not surprising that someone else thought of it first.

Maybe I'll get round to writing a PHP and/or PAM lib to implement it.

Sunday, 28 September 2008

Authentication tokens


Devices like hashing fobs or tamper-proof smart cards are technically the best solutions for secure authentication - but they have a number of drawbacks for proactical applications. By far the biggest one is that they are not universal - I can't use my Paypal fob to log onto my LAN, I have several smart cards in my wallet, but where do I get a reader? Even if I did, how would I get Google to support the use of the card for accessing my gmail account?


Instead we seem doomed to endure badly implemented wish-it-was-2-factor-authentication and Capchas which even those of us lucky enough not to be visually impaired, cannot read.


While kitten capchas are undoubtedly cute, do they really help solve the problem?


It occurred to me that not entering the same password more than once is a good way to avoid the risk of compromise (essentially this is the common factor in Capchas, smart cards and key fobs) and here is a simple way to achieve this:


When you create an account for your user, issue them with a grid of letters and digits, 6x6 seems about right.

























ABCDEF
1sar3cv
28teyp4
3qighwk
4fmzbi9
57djanp
6geu59w


Then, each time they log in, ask for, say 5 of the entries, the grid holds more than 8000 passwords.


Given say 32 possible keys (omitting the letter O and number 0, lower case L and digit 1) the chance of guessing the password are one in 33 million.


Someone's probably already thought of this. But I thought I'd write it down before it gets patented.

Monday, 1 September 2008

Microsoft backdoor optimization?

I recently replied to a post on uk.comp.os.linux regarding squid - but on reflection, if the details supplied by the OP are correct, then this exposes some backdoor optimization by Microsoft in IIS

The post and replay are here.

Tim said that:

tim@feynman:~$ telnet www.plumbcenter.co.uk 80
Trying 89.207.160.30...
Connected to www.plumbcenter.co.uk.
Escape character is '^]'.
GET /plumb/index.html HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

HTTP/1.1 400 Bad Request
Date: Wed, 27 Aug 2008 21:44:51 GMT
Server: Microsoft-IIS/6.0
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
(404 body snipped)

Connection closed by foreign host.

This works if you drop the "; SV1" from the user agent. Or even replace
"; SV1" with "; SV2" or replace "5.1" with "5.0" but leave the "; SV1"
bit!

What's interesting here is that the request headers specify HTTP/1.0 but the response comes back from the server as HTTP/1.1

While maybe this is just sloppy programming by Microsoft, its worth bearing in mind that, by default MSIE degrades to HTTP/1.0 responses when it knows it's talking via a proxy. Also, HTTP/1.1 mainly addresses performance improvements.

Further - as Tim points out, the behaviour of the server changes when the user-agent changes.

Could it be that IIS is using the user-agent for purposes beyond what it should do according to spec? This could give Microsoft an unfair performance advantage over other browsers. Certainly in this case there is hard evidencethat the server is basing its response on the user-agent supplied in the request.

For the time being this is mostly conjecture and conspiracy theory. But it would be interesting to confirm whether IIS always responds to HTTP/1.0 requests with a HTTP/1.1 response, whether it will include HTTP/1.1 specific browser instructions - and to see if the browser then acts on these.

Friday, 8 August 2008

KISS

Today I'm looking at monitoring the throughput of a mail server running RHEL5. Unfortunately the default check_mailq supplied with Nagios just looks at the size of the number of messages in the mailq.

Another problem I encountered was that mailq is not setuid root on this distro. Rather than reinvent the wheel, I thought I'd have a look at how RH & sendmail measure the size of the queue.
  • /usr/bin/mailq is a symlink to /etc/alternatives/mta-mailq
  • /etc/alternatives/mta-mailq is a symlink to /usr/bin/mailq.sendmail
  • /usr/bin/mailq.sendmail is a symlink to /usr/sbin/sendmail
  • /usr/sbin/sendmail is a symlink to /etc/alternatives/mta
  • /etc/alternatives/mta is a symlink to /usr/sbin/sendmail.sendmail
...of course!