[tboot] Add patch to fix timeout bug introduced by tboot.hg changeset 176.
Either the TPM in the hp6930p doesn't operate to spec or the code
was never tested. With the patch, the values read from the tpm are
equal to the default values used before tpm timeout code was added
in changesets 163 and 176.
[package xenclient-ioemu] Target Env was applied to "cd" builtin rather
than the xen-setup command. This was causing the configure to fail
because of missing headers and libraries.
David Halls [Sun, 24 Jan 2010 22:42:30 +0000 (22:42 +0000)]
See email thread below.
Briefly:
- Make curl's test for same user and password before re-using a connection more robust.
- Once auth has finished (succeed or fail), close the connection. This stops the connection being re-used for auth
again later, which confuses curl!
------ EMAIL THREAD STARTS HERE ------
A slight modification. I modified libcurl to do these things:
- Check user name and password match before re-using a connection.
o This ensures that if we ever had multiple, concurrent users, there is no chance a user would end up authenticated as someone else.
- Close the connection once auth has succeeded or failed.
o This ensures that a user won't end up re-using a connection from a previous auth. Curl's state machine doesn't like this. It's probably safest anyway.
- Put a 32 byte random string in the password field (while picking up the NT hash from a file).
o This is to protect against multiple _concurrent_ auth attempts from the _same_ user. Without this, the auth attempts might interfere and fail.
What do you think? I've done these changes outside XenClient so far and will fold them in tomorrow if they seem okay.
David
From: David Halls
Sent: 22 January 2010 18:25
To: Jean-Sebastien Legare
Cc: Ian Pratt; Jean Guyader; Chris Mayers
Subject: libcurl
OK so I found an unpleasant feature of libcurl today: it doesn't quite get NTLM right on its connections.
It doesn't mark NTLM connections as being in use for NTLM so in theory if it decides to re-use a connection doing NTLM, things can fail in weird ways. Here's the bug report I subsequently found:
37. Having more than one connection to the same host when doing NTLM
authentication (with performs multiple "passes" and authenticates a
connection rather than a HTTP request), and particularly when using the
multi interface, there's a risk that libcurl will re-use a wrong connection
when doing the different passes in the NTLM negotiation and thus fail to
negotiate (in seemingly mysterious ways).
It also screws up if you happen to re-use a connection that's previously done NTLM, and want to do NTLM again (the existing bed test harness found that - well done whoever wrote that). It says the authentication is in a bad state. This is because it just re-uses the connection as it's to the same host.
What I've done so far for a fix is to modify curl's connection re-use logic like so:
- if a connection has a username and password associated with it, then it can only be re-used if the new request has a username and password; AND
- the username and password on the connection must match those on the request
This ensures that:
- NTLM still works since the challenge-response multiple requests is performed over the same connection
- connections aren't re-used inadvertently, and that when we do re-use them, it's for the same user. [In XenClient, we only do NTLM to login - after that, we use pass headers around to prove the user is logged on. So we don't need to re-use the authenticated connections.]
However, there remains one problem. If a second NTLM authentication (i.e. login) is required for the same user for any reason, and the first connection is still alive, then it fails. This is because the user name and passwords will match and the first connection will be re-used - and curl's state machine gets into a state.
So I have a workaround for this. We don't actually set any password - we pick the hash up from a file. So if I set the password field to a random string, everything works.
What do you think to this solution? Is it safe enough (I guess a long enough random string should be ok?)
projects / xenclient / build.git / log