On 20/06/2008, at 4:22 PM, Simo Leone wrote:
On Fri, Jun 20, 2008 at 12:54:29AM +0800, Callan Barrett wrote:
Here's another iteration of this patch, I'm still looking for as much input as possible but this is basically what I would push to testing at this point. The script now outputs in a different format to be parsed and there is some cleanup done in pkgsubmit.php to get it working more cleanly with the script.
Unfortunately Callan and I found a way to easily defeat this tonight, the proof-of-concept is attached, the attack is based on this little bit about restricted shells (from the manpage): --- When a command that is found to be a shell script is executed (see COM- MAND EXECUTION above), rbash turns off any restrictions in the shell spawned to execute the script. ---
Too bad too, real bash parsing would have been nice :/
-S <script.txt><PKGBUILD.txt><fucked.sh>
Perhaps we should write up our own tiny little bash parser. I've never really done anything like that before, but after a little googling I found two tools that could simplify the whole process a lot; Lex and YACC. Lex tokenizes the source code and YACC recognizes higher-level patterns (expressions, assignments, etc). I believe the output of YACC is compiled as a C program, so we could run that and use the output somehow. We mostly only deal with assignments, which should be fairly straight forward. I have seen a few (official) PKGBUILDs that used loops to generate the source and md5sums arrays, so we might want to support that as well. Of course doing so would introduce the problem with infinite loops. "If" statements (both the traditional syntax and the shorthand) would probably be necessary, since checksums may be different for different architectures (different blob for each architecture). I don't see any harm in supporting those. Of course going down this path means a LOT more work and most likely a lot more bugs and hair pulling. On the other hand we do have very tight control over the parsing and we can modify it at will.