The problem is that there is a bug in the busybox loop dealing with interspursed input and output. You MUST read all the post data before sending any output, otherwise you risk a hang.
You can work around it by moving all the reads to the top :?
Topic: Web-Interface Poll
The content of this topic has been archived between 21 Mar 2018 and 6 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
Page 2 of 2
This definitely looks exploitable. There is no length checking applied to wbuf anywhere in that code, nor is there a hard-coded null assignment for wbuf[127]. bb_full_write() (see libbb/full_write.c) does no length limit checking, and calls safe_write() (see libbb/safe_write.c), which also doesn't do any length checking and calls write(2) blindly.
Has anyone: contacted the busybox folks about this before something Bad(tm) happens? Looks like grounds for a CERT advisory, but it's always best to talk to the authors about things first, especially before an exploit comes out or something of that nature.
Line 1246 prevents reads > sizeof(wbuf) into wbuf.
Also NUL characters CAN (and probably will) be in the POST data, so there's no bug there. Nobody's doing strlen(wbuf).
You're completely and totally correct. I just discussed this with mjn3; I *COMPLETELY* missed line 1246 in my original audit.
This code does NOT look to be exploitable. I was incorrect in my original statement.
About the infinite loop: I have no idea on that one.
I have an idea of what might be going on, but I'm not sure of the fix.
select() setting the bit means that write() will not block. HOWEVER, an arbitrary-sized write (i.e., not 1 byte) might block!
The same is true for a read. Just thinking about this point, not sure.
this is the sort of thing i'm interested in:
http://home.eol.ca/~parkw/index.html#basp
http://freshmeat.net/projects/basp/
obviously for our purposes it would be better to implement this via a bash script or standalone c app rather than patching busybox
why not use normal ash like that
#!/bin/ash
cat << EOF
<html><head></head><body><span style="font-family: verdana; font-size:22">$(uname -a)</span></body></html>
EOFi've already started working on a modular frontend this way..
Aight! Why do all you dudes start working on a own webinterface? Atm, there is one cgi, one php and your interface .. Couldn't you get together, and write an own interface together? 
You guys should have a look at appweb.
nico made a package.
Atm, plain html doesnt seem to work, and neither does directoryindex
but otherwise, the .esp pages work
saldaNa wrote:
why not use normal ash like that
#!/bin/ash cat << EOF <html><head></head><body><span style="font-family: verdana; font-size:22">$(uname -a)</span></body></html> EOF
i don't really ahve a problem with this method. mbm suggested this a while back. i just think there might be a way to let you embed more then just expansions.
with this method, if you want to use conditionals and loops you need separate cat statements. not that it doesn't work, i've just wondered how hard it would be to write a parser that could handle something like:
<html> <% for i in $some_list; do echo $i done %> </html>
i realize that can be handled with the above method, but it's not "pretty," which may not matter...
well can be handled diffrent
<html>
cat << EOF
$(uname -a)
EOF
for i in $some_list; do
echo $i
done
cat << EOF
$(uptime)
EOFnot pretty but doesn't waste space
You can check what I did out here: http://divdb.com/www.tar
uh, 404 dude 
The discussion might have continued from here.
Page 2 of 2