Jump to content




Load wrapper loophole [CC1.8 and some earlier versions]


7 replies to this topic

#1 EveryOS

  • Members
  • 569 posts
  • LocationBOO!!

Posted 24 March 2018 - 02:48 AM

local fenv = getfenv(load)
fenv._G = fenv
fenv.error = function() end
setfenv(load, fenv)
load(string.dump(function() print("HI") end), "X", "b", _G)()

See "more correct" revision of code below. It does not affect _G, unlike this version
This shouldnt work...

Edited by EveryOS, 26 March 2018 - 03:13 PM.


#2 Lupus590

  • Members
  • 2,027 posts
  • LocationUK

Posted 24 March 2018 - 12:58 PM

b flag in load function is for binary chunks, which should be blocked by the bios

What version of CC is this, have you replicated the issue on latest?

Edited by Lupus590, 24 March 2018 - 12:59 PM.


#3 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 24 March 2018 - 03:03 PM

View PostLupus590, on 24 March 2018 - 12:58 PM, said:

b flag in load function is for binary chunks, which should be blocked by the bios
Eh. It doesn't actually validate that elsewhere, so you can still load binary flags by passing nil. Given that CC runs LuaJ instead of PUC Lua, it's really not a big issue - you can't actually exploit bytecode at all.

#4 EveryOS

  • Members
  • 569 posts
  • LocationBOO!!

Posted 24 March 2018 - 09:53 PM

View PostLupus590, on 24 March 2018 - 12:58 PM, said:

should be blocked by the bios
Here is the best proof I can give: Posted Image
Though I cannot show you that I have not modified the environment, you can try it for yourself.

BTW,

View PostSquidDev, on 24 March 2018 - 03:03 PM, said:

you can't actually exploit bytecode at all.

View PostLyqyd, on 19 August 2015 - 12:10 AM, said:

Obfuscated downloads are not allowed.
Bytecode exploit: write a script that deletes all files, compile it to bytecode, base64 it, write what appears to be an installer, de-base64 it at runtime, and pass the result into the hacked load.

Edited by EveryOS, 25 March 2018 - 01:20 AM.


#5 EveryOS

  • Members
  • 569 posts
  • LocationBOO!!

Posted 25 March 2018 - 12:01 AM

More "correct" version of the code that will not override the global env. The previous code still shows the point, but was not 100% correct.

local fenv = {}
for k, v in pairs(getfenv(load)) do fenv[k] = v end
fenv._G = fenv
fenv.error = function() end
setfenv(load, fenv)
load(string.dump(function() print("HI") end), "X", "b", _G)()

Previously _G.error would be overrided, this still shows the point without doing that.

Edited by EveryOS, 25 March 2018 - 12:02 AM.


#6 apemanzilla

  • Members
  • 1,421 posts

Posted 26 March 2018 - 03:17 PM

View PostEveryOS, on 24 March 2018 - 09:53 PM, said:

View PostSquidDev, on 24 March 2018 - 03:03 PM, said:

you can't actually exploit bytecode at all.

View PostLyqyd, on 19 August 2015 - 12:10 AM, said:

Obfuscated downloads are not allowed.
Bytecode exploit: write a script that deletes all files, compile it to bytecode, base64 it, write what appears to be an installer, de-base64 it at runtime, and pass the result into the hacked load.

That's not really an exploit, and regardless, you can do that with source code to the same effect.

#7 EveryOS

  • Members
  • 569 posts
  • LocationBOO!!

Posted 26 March 2018 - 03:18 PM

But still, I would think there would be a point to the (rather badly coded) load wrapper
Also, bytecode is still further from readable then source code. Plus, if you convert the hard-to-read source code to bytecode, it's even harder to read.

Edited by EveryOS, 26 March 2018 - 03:20 PM.


#8 ardera

  • Members
  • 503 posts
  • LocationGermany

Posted 30 March 2018 - 05:04 PM

View PostEveryOS, on 24 March 2018 - 09:53 PM, said:

Bytecode exploit: write a script that deletes all files, compile it to bytecode, base64 it, write what appears to be an installer, de-base64 it at runtime, and pass the result into the hacked load.
Or, instead of doing that, you could just delete all files in the installer script. Maybe add 200 whitespaces in the first line and after that the malicious code in the same line so noone will know.
That's way sneakier than de-base64-ing some string and loading it.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users