5 ms·

Lua isn't mentioned there, so I'd like to ask: since Lua interns every string, isn't it vulnerable even if a framework doesn't put request parameters into the t

by dchest 15y ago

Lua isn't mentioned there, so I'd like to ask: since Lua interns every string, isn't it vulnerable even if a framework doesn't put request parameters into the table?

finnw 15y ago
Yes, and it also uses a weak hash function by design (for performance reasons it only looks at a few characters not the whole string.)
extension 15y ago
Lua's string hash function looks roughly like this: hash = length of string for each char c in string hash = hash ^ ((hash << 5) + (h >> 2) + (unsigned char) c) It folds up to 32 chars into the hash. If the string is longer, it skips some characters. This is a well known hash function and it's very different from the one being used by all the other vulnerable languages, but I don't know how hard it is to find collisions for this one.
- silentbicycle 15y ago
  The full source (as of 5.2) is here (http://www.lua.org/source/5.2/lstring.c.html#luaS_newlstr http://www.lua.org/source/5.2/lstring.c.html#luaS_newlstr).
- mikeash 15y ago
  If it starts skipping characters in longer strings then I'd say it's trivial to find collisions by simply constructing strings that are identical in the bytes that are examined and differ in the bytes that aren't.
- colanderman 15y ago
  It looks like it would be trivial to find collisions; all the functions used (xor, bitshifts, and addition) are trivially reversible. Just replace the nondeterminism of reversing the binary operators (xor and addition) with a random number generator and you've got yourself a collision generator.
josephcooney 15y ago
C#/.NET is also not mentioned. Clearly I'm out of touch, I hadn't realized that Rubinius and JRuby were more popular than C# and VB.NET. Anyone have any idea if/how .NET might be impacted by this?
- dchest 15y ago
  There's ASP.NET.
- Groxx 15y ago
  They mentioned .NET in the video that sonnym linked here: http://news.ycombinator.com/item?id=3402152 http://news.ycombinator.com/item?id=3402152 Sorry, I was skipping through it at that point (2/3 of the way through?), I don't know what their conclusion was. I think they said that it was partially different but still likely attackable, but I didn't catch it all.
- philjr 15y ago
  Very vulnerable, it uses a variant of DJB's common hash functions. Check out the youtube video posted elsewhere in the thread for a great summary
- Encosia 15y ago
  Vulnerable, but a patch is being released tomorrow night: http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-se...
  - ams6110 15y ago
    From that link: On Dec 28th 2011, details were published at a security conference describing a new method to exploit hash-table data-structures From what I've been reading, this sounds like something that's not new at all and in fact has been an open vulnerability for years.

by dchest 15y ago

Lua isn't mentioned there, so I'd like to ask: since Lua interns every string, isn't it vulnerable even if a framework doesn't put request parameters into the table?

finnw 15y ago

Yes, and it also uses a weak hash function by design (for performance reasons it only looks at a few characters not the whole string.)

extension 15y ago

Lua's string hash function looks roughly like this: hash = length of string for each char c in string hash = hash ^ ((hash << 5) + (h >> 2) + (unsigned char) c) It folds up to 32 chars into the hash. If the string is longer, it skips some characters. This is a well known hash function and it's very different from the one being used by all the other vulnerable languages, but I don't know how hard it is to find collisions for this one.

silentbicycle 15y ago
The full source (as of 5.2) is here (http://www.lua.org/source/5.2/lstring.c.html#luaS_newlstr http://www.lua.org/source/5.2/lstring.c.html#luaS_newlstr).
mikeash 15y ago
If it starts skipping characters in longer strings then I'd say it's trivial to find collisions by simply constructing strings that are identical in the bytes that are examined and differ in the bytes that aren't.
colanderman 15y ago
It looks like it would be trivial to find collisions; all the functions used (xor, bitshifts, and addition) are trivially reversible. Just replace the nondeterminism of reversing the binary operators (xor and addition) with a random number generator and you've got yourself a collision generator.

josephcooney 15y ago

C#/.NET is also not mentioned. Clearly I'm out of touch, I hadn't realized that Rubinius and JRuby were more popular than C# and VB.NET. Anyone have any idea if/how .NET might be impacted by this?

dchest 15y ago
There's ASP.NET.
Groxx 15y ago
They mentioned .NET in the video that sonnym linked here: http://news.ycombinator.com/item?id=3402152 http://news.ycombinator.com/item?id=3402152 Sorry, I was skipping through it at that point (2/3 of the way through?), I don't know what their conclusion was. I think they said that it was partially different but still likely attackable, but I didn't catch it all.
philjr 15y ago
Very vulnerable, it uses a variant of DJB's common hash functions. Check out the youtube video posted elsewhere in the thread for a great summary
Encosia 15y ago
Vulnerable, but a patch is being released tomorrow night: http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-se...
- ams6110 15y ago
  From that link: On Dec 28th 2011, details were published at a security conference describing a new method to exploit hash-table data-structures From what I've been reading, this sounds like something that's not new at all and in fact has been an open vulnerability for years.