On Sat, Jun 27, 2009 at 06:00:32PM +0200, Julien Valroff wrote:
[...]
> I am not a security expert, and I am not sure to understand how
> your patch would make ajaxterm really secure. From what I could
> read, Math.random() is said to be inherently insecure.
Well, the primary concern (according to my reading of the original
report) was that ajaxterm generated very simple IDs, which could be
easily tried in sequence to rapidly hijack existing sessions
(possibily leading to system compromise if in use for shell access).
Having only digits meant the maximum number of unique combinations
of characters was 10 raised to the power of the ID length. Adding
mixed-case letters increased this to 62 raised to the power of the
ID length, which meant a significantly greater number of
possibilities making it much harder to guess an existing session ID.
As I said in a previous update, increasing the ID length could
provide some improvement here as well.
A secondary concern raised by the report was that sending HTTP
requests with lots and lots of different made-up session IDs could
effectively consume resources on the server, leading to a denial of
service. This would generally be considered a less severe
vulnerability, but one which requires much more effort to mitigate.
The usual solution would be to generate IDs server-side, and have
the application refuse to open sessions for IDs which weren't valid.
> Would the proposed code add sufficient randomisation to guarantee
> ajaxterm security?
There are no measures which guarantee security. Of course, if there
were, many of us would need to find a new line of work. ;)
That being said, I feel that increasing the field which needs to be
enumarated to brute-force a session ID already in use helps improve
the situation with only a trivial modification to the existing code.
As much as I'd rather not see the ajaxterm package dropped from
Debian's archive (because I rely on it as a console-to-HTTP
interface for some chrooted or otherwise neutered applications, not
for such risky things as shell access), I'm not personally willing
to take on the task of becoming its upstream maintainer either.
> As said, I am just trying to understand better before applying the
> patch and upload this fix to Debian.
I'd like to be able to take the time to understand it better as
well, but I generally don't get much opportunity to do more than
fill a few cracks and move on. Hopefully my proposed patch isn't
ineffectual, and doesn't introduce further vulerabilities due to my
unfamiliarity with other parts of the application.
> Any comment from the Security team would be welcome!
As would I. Admittedly, Javascript is not my strong suit. I browsed
around a little and didn't see any obvious reports that
Math.Random() is itself highly predictable (though this wouldn't
surprise me either). I do agree, however, that my patch does little
more than raise the bar for brute-forcing sessions, and that a
proper fix would get rid of client-generated session IDs all
together.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
