From hutch-lists at recursive.ca  Fri Oct 10 16:00:41 2008
From: hutch-lists at recursive.ca (Bob Hutchison)
Date: Fri, 10 Oct 2008 12:00:41 -0400
Subject: [hunchentoot-devel] Troubles on OS X with Hunchentoot
In-Reply-To: <611F2FD6-D6D3-44CB-BEB2-38C019978D90@recursive.ca>
References: <611F2FD6-D6D3-44CB-BEB2-38C019978D90@recursive.ca>
Message-ID: <561F6998-C27D-4FC0-8976-9E66E249F649@recursive.ca>

I got a response to this problem on the lispworks mailing list.


On 10-Oct-08, at 10:02 AM, Pascal Costanza wrote:

>
> Hi there,
>
> Yes, this is Leopard's weird security system. In the firewall  
> settings of your system, don't select "Set access for specific  
> services and applications", but only either "Allow all incoming  
> connections" or "Allow only essential services."
>
> Leopard stores firewall settings per application in the application  
> file itself when you select the wrong option here, and this destroys  
> the LispWorks image.
>
>
> Pascal
>
> On 9 Oct 2008, at 23:14, Bob Hutchison wrote:
>
> -- 
> Lisp50: http://www.lisp50.org
>
> Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>
> On 9-Oct-08, at 5:15 PM, Bob Hutchison wrote:
>
>> Hi,
>>
>> On occasion when I'm running Hunchentoot in LW 5.5.1 when I quit  
>> then restart LW I get the following error:
>>
>> Lisp executable xfasl-image.static apparently corrupted.  
>> (Truncated?) Cannot restart.
>>
>> I'm having to copy the LispWorks.app from a backup overtop the  
>> version in /Applications/...
>>
>> Any idea what might be causing this?
>>
>> I'll be asking on the LispWorks mailing list as well.
>>
>> Cheers,
>> Bob
>



From arbscht at gmail.com  Thu Oct 16 19:14:21 2008
From: arbscht at gmail.com (Abhishek Reddy)
Date: Fri, 17 Oct 2008 08:14:21 +1300
Subject: [hunchentoot-devel] Broken port-clisp.lisp under CLISP 2.44 [patch]
Message-ID: <6da08ade0810161214j1c2a1848xec1140c3cb01a8ce@mail.gmail.com>

Hello,

Hunchentoot 0.15.7 fails to compile under CLISP 2.44 (GNU/Linux), with
this message[1].

In port-clisp.lisp, there is a call to SYS::FRAME-UP-1.  As of CLISP
2.44, this is an unavailable function name.  It was replaced[2] by
(SYS::FRAME-UP 1 ...).

This issue has been addressed[3] in more recent swank-clisp.lisp
versions.  Below[4] is a patch adapted from there.  It adds a symbol
to *features* depending on CLISP's version, upon which it
conditionally calls the right frame-up function.

Cheers,
Abhishek.

[1]
;; Compiling file
/home/abhishek/.clc/site/hunchentoot-0.15.7/port-clisp.lisp ...
** - Continuable Error
INTERN("FRAME-UP-1"): #<PACKAGE SYSTEM> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
The following restarts are also available:
RETRY          :R1      Retry performing #<ASDF:COMPILE-OP NIL
#x204E54BE> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x204DC7EE>.
ACCEPT         :R2      Continue, treating #<ASDF:COMPILE-OP NIL
#x204E54BE> on #<ASDF:CL-SOURCE-FILE "port-clisp" #x204DC7EE> as
having been successful.
ABORT          :R3      Abort main loop

[2] http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/src/ChangeLog?r1=1.5922&r2=1.5921

[3] http://github.com/pat-maddox/slime/commit/0ad4624b6f1d5c6bcfc773dcb2452dd4fe2d4f43

[4]
diff -u port-clisp.lisp port-clisp.lisp.new
--- port-clisp.lisp     2008-10-17 08:13:11.000000000 +1300
+++ port-clisp.lisp.new 2008-10-17 07:13:58.000000000 +1300
@@ -109,13 +109,19 @@
 is a function frame."
   (char= #\< (aref formatted-frame 0)))

+(eval-when (:compile-toplevel :load-toplevel :execute)
+  (when (string< "2.44" (lisp-implementation-version))
+    (pushnew :clisp-2.44+ *features*)))
+
 (defun get-backtrace (error)
   "This is the function that is used internally by Hunchentoot to
 show or log backtraces."
   (declare (ignore error))
   (with-output-to-string (stream)
     (do ((last nil frame)
-         (frame (sys::the-frame) (sys::frame-up-1 frame 1)))
+         (frame (sys::the-frame)
+                #+clisp-2.44+ (sys::frame-up 1 frame 1)
+                #-clisp-2.44+ (sys::frame-up-1 frame 1)))
         ((eq frame last))
       (let ((formatted-frame (format-frame frame)))
         (when (function-frame-p formatted-frame)



From hans at huebner.org  Fri Oct 24 11:43:18 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 24 Oct 2008 13:43:18 +0200
Subject: [hunchentoot-devel] Fwd: hunchentoot session hijacking
In-Reply-To: <fd2982320810240354wc1c1a5fiafb5391b6a5d35af@mail.gmail.com>
References: <421554543.20081024003842@yandex.ru>
	<fd2982320810240354wc1c1a5fiafb5391b6a5d35af@mail.gmail.com>
Message-ID: <fd2982320810240443s5c2d88fw8ef98f893d524534@mail.gmail.com>

Hi,

forwarding an off-list discussion.  Please review and comment to the list.

Thanks,
Hans


---------- Forwarded message ----------
From: Hans H?bner <hans at huebner.org>
Date: Fri, Oct 24, 2008 at 12:54
Subject: Re: hunchentoot session hijacking
To: Anton Vodonosov <avodonosov at yandex.ru>
Cc: Edi Weitz <edi at agharta.de>


Hi Anton,

thank you for your security analysis.  I agree that, even though the
weakness of the session protection is documented, it would be better
to provide for a secure scheme from the beginning.  The problem at
hand is that there is no portable secure solution.  Adding a
documented hook to Hunchentoot that allows for setting up a more
secure scheme is certainly possible, but I think that this would not
be beneficial:  Such a hook is trivial, and the concerned user can
always implement HUNCHENTOOT:RESET-SESSION-SECRET in a more secure
fashion, overriding the default implementation.

Another option would be to make specifying a part of the session
secret mandatory at server startup time.  I would find this
inconvenient, in particular if it cannot be demonstrated that the
scheme would be substantially more secure than the existing mechanism.
 Another option would be to provide for a portable secure
implementation, but I certainly lack the time to look at this.

So, if you feel that this is something that needs to be addressed, can
you provide us with a patch, either to the source code or to the
documentation?  A documentation patch could consist of a short summary
of your security analysis and a description how the concerned user can
make the server more secure.

Thanks,
Hans

On Thu, Oct 23, 2008 at 23:38, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> Hello.
>
> I've recently discovered that hunchentoot sessions are quite easy to
> hijack (while I was investigating generation of unpredictable keys
> for cl-openid). Therefore I want to suggest a solution to make them
> more secure.
>
> I know the documentations discourages from considering sessions as
> really secure, but after some experiments it turned out that in normal
> case it is a matter of just several hours to hijack hunchentoot
> sessions.
>
> For example, I know that the hunchentoot-session cookie value is
> "2561%3A5767E844C4A3FBEDBCA79C349F1DE52B; path=/".
>
> 2561 here is SESSION-ID. 3A5767E844C4A3FBEDBCA79C349F1DE52B is value
> produced by
>  (encode-session-string
>     (session-id session)
>     (session-user-agent session)
>     (session-remote-addr session) ;; usually ignored
>     (session-start session)))
>
> I know my SESSION-USER-AGENT. SESSION-START is most likely the
> value of the Date header in the server response.
>
> The only unknown value is the *SESSION-SECRET* global used by
> ENCODE-SESSION-STRING. But it is easy guessable. It is generated by a
> series or RANDOM invocation. RANDOM implementation is usually deterministic,
> and therefore *SESSION-SECRET* is fully determined initial value of
> *THE-RANDOM-STATE*, which in turn is usually fully determined by current
> time (i.e. server startup time). I.e. *SESSION-SECRET* is fully
> determined by the server start time.
>
> For example in SBCL, MAKE-RANDOM-STATE uses GET-UNIVERSAL-TIME.
> Resolution of GET-UNIVERSAL-TIME is one second i.e. if we want
> to consider a year-long period, we have only (* 365 24 60 60)
> == 31536000 values to consider. This took several hours of a
> moderate laptop.
>
> After we know *SESSION-SECRET*, we may easy calculate session cookie
> for any given session ID (we usually do not know session start
> time of other people, but it is in the range of 30 minutes from current
> time for active sessions).
>
> In short, to make session more secure we need unguessable
> *SESSION-SECRET*. It is possible to use /dev/[u]random on Linux
> and CryptoAPI on Windows, but the simplest way, in my opinion,
> would be to provide a public function to set session secret (or a
> part of session secret). User will set it to some passphrase.
>
> Best regards,
> - Anton
>
>
>
>
>



From avodonosov at yandex.ru  Sun Oct 26 04:48:28 2008
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Sun, 26 Oct 2008 06:48:28 +0200
Subject: [hunchentoot-devel] Fwd: hunchentoot session hijacking
In-Reply-To: <fd2982320810240443s5c2d88fw8ef98f893d524534@mail.gmail.com>
References: <421554543.20081024003842@yandex.ru>
	<fd2982320810240354wc1c1a5fiafb5391b6a5d35af@mail.gmail.com>
	<fd2982320810240443s5c2d88fw8ef98f893d524534@mail.gmail.com>
Message-ID: <667197057.20081026064828@yandex.ru>

on Friday, October 24, 2008, 1:43:18 PM Hans wrote:

> So, if you feel that this is something that needs to be addressed, can
> you provide us with a patch, either to the source code or to the
> documentation?  A documentation patch could consist of a short summary
> of your security analysis and a description how the concerned user can
> make the server more secure.

Hi.

My suggestion is in the patch attached. It introduces new variable
*session-secretizer* which is supposed to be set by the concerned user
to some secret value. *session-secretizer* is used as a part of
*session-secret*. If it is not set, *session-secret* is generated as
before, but a WARN is issued.

Perhaps *session-secretizer* is a stupid name, but I was not able to
contrive anything better, taking into account that *session-secret*
is already busy.

Also attached is a small patch to cl+ssl in your repository that
makes it compilable on sbcl win32.

Best regards,
- Anton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: session-secretizer.diff
Type: application/octet-stream
Size: 3419 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20081026/03e2a2a7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl+ssl.diff
Type: application/octet-stream
Size: 633 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20081026/03e2a2a7/attachment-0001.obj>

From hans at huebner.org  Mon Oct 27 10:16:42 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 27 Oct 2008 11:16:42 +0100
Subject: [hunchentoot-devel] Fwd: hunchentoot session hijacking
In-Reply-To: <667197057.20081026064828@yandex.ru>
References: <421554543.20081024003842@yandex.ru>
	<fd2982320810240354wc1c1a5fiafb5391b6a5d35af@mail.gmail.com>
	<fd2982320810240443s5c2d88fw8ef98f893d524534@mail.gmail.com>
	<667197057.20081026064828@yandex.ru>
Message-ID: <fd2982320810270316v7b847570j8b9daf4034d101f9@mail.gmail.com>

Hi Anton,

thank you for the patches.  I have committed the CL+SSL patch both
upstream and in my repository.

For the session secret update:

- The name *SESSION-SECRETIZER* really does not cut it.  I would
suggest that *SESSION-SECRET-SALT* is more suitable.
- The docstring and documentation file should be clear about the
expected datatype of the variable (string?)
- I don't like the warning if the only way to set up the salt is
setting the special variable.
- Maybe it would be better to supply the concerned user with a way to
override the ENCODE-SESSION-STRING function instead of having them
mess with the internals of the current session secret encoding
function.

I would like to know what Edi thinks about this before committing this
or any other patch to the repository.

-Hans



From avodonosov at yandex.ru  Mon Oct 27 23:20:56 2008
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Tue, 28 Oct 2008 01:20:56 +0200
Subject: [hunchentoot-devel] Fwd: hunchentoot session hijacking
In-Reply-To: <fd2982320810270316v7b847570j8b9daf4034d101f9@mail.gmail.com>
References: <421554543.20081024003842@yandex.ru>
	<fd2982320810240354wc1c1a5fiafb5391b6a5d35af@mail.gmail.com>
	<fd2982320810240443s5c2d88fw8ef98f893d524534@mail.gmail.com>
	<667197057.20081026064828@yandex.ru>
	<fd2982320810270316v7b847570j8b9daf4034d101f9@mail.gmail.com>
Message-ID: <19810042213.20081028012056@yandex.ru>

on Monday, October 27, 2008, 12:16:42 PM Hans wrote:

> Hi Anton,

> thank you for the patches.  I have committed the CL+SSL patch both
> upstream and in my repository.

> For the session secret update:

> - The name *SESSION-SECRETIZER* really does not cut it.  I would
> suggest that *SESSION-SECRET-SALT* is more suitable.
Yes, that's better :)

> - The docstring and documentation file should be clear about the
> expected datatype of the variable (string?)
Yes, I forgot. It must be string.

> - I don't like the warning if the only way to set up the salt is
> setting the special variable.
> - Maybe it would be better to supply the concerned user with a way to
> override the ENCODE-SESSION-STRING function instead of having them
> mess with the internals of the current session secret encoding
> function.

Overriding ENCODE-SESSION-STRING is more complex responsibility
for users - they must deal with four parameters: session-id,
user-agent, remote-addres and session-start-time; and with
*USE-USER-AGENT-FOR-SESSIONS*, *USE-REMOTE-ADDR-FOR-SESSIONS*; and
they must understand that the result must unique and unguessable.

I also thought about providing a possibility to overrride
RESET-SESSION-SECRET, as  you suggested in the previous email (btw,
how "overrride"? just redefine or clos-specialize on artificially
introduced parameter). But in this case we need to export both
RESET-SESSION-SECRET and *SESSION-SECRET* and explain people that
generated secret must every time be not only unguessable but also
unique, which is an extra responsibility for them.

Therefore, although I do not like too much introduction of the new
special variable, it is the simplest way I see. The only thing
we need is the salt, and users just provide it. Hunchentoot does
all the remaining job.

> I would like to know what Edi thinks about this before committing this
> or any other patch to the repository.

Ok.

Best regards,
- Anton