Re: [Bug-wget] Wget tests
On Montag, 15. August 2016 15:06:52 CEST Dale R. Worley wrote:
> Can someone give me a hint how the wget tests work? The test
> directories seem to contain no high-level documentation. As far as I
> can tell, the pairs of files *.{trs,log} either are or correspond to the
> various tests, but I can't find the file(s) that specify what the test
> invocations of wget are, nor what files the test HTTP server sees.
We use standard automake tests (search the internet if you are interested in
details).
We have the 'legacy' tests/ directory with tests written in Perl. And the
'current' testenv/ directory with tests written in Python.
See tests/Makefile.am resp. testenv/Makefile.am for the list of executed tests.
The output of each test executed by 'make check' is saved in a .log file.
You can execute a single test with e.g.
$ cd tests
$ make check TESTS=Test--start-pos
(creates a .log file)
or with e.g.
$ cd tests
$ ./Test--start-pos.px
(prints output on screen, creates no .log file)
Regards, Tim
signature.asc
Description: This is a digitally signed message part.
[Bug-wget] problems with some wget versions for LDAP authentication
Hello, we use an LDAP authentication scheme on our servers at GES DISC NASA GSFC to authenticate data access. We discovered that some wget versions do not correctly pass credentials to the LDAP server. To our knowledge wget 1.12 and lower as well as wget 1.17 do not work as expected and wget 1.14, 1.15 and 1.18 work. I will greatly appreciate if you could look into this and see if you correct issue in wget past 1.14 as we advise to our users to download wget 1.14 and higher. To replicate the issue just follow three steps on http://disc.sci.gsfc.nasa.gov/registration A sample URL to try after above steps are performed is: wget --content-disposition --load-cookies ~/.urs_cookies --save-cookies ~/.urs_cookies --auth-no-challenge=on --keep-session-cookies "http://acdisc-ts1.gesdisc.eosdis.nasa.gov/daac-bin/OTF/HTTP_services.cgi?FILENAME=%2Fdata%2Fs4pa%2FAura_OMI_Level2G%2FOMTO3G.003%2F2005%2FOMI-Aura_L2G-OMTO3G_2005m0101_v003-2012m0404t152005.he5&FORMAT=SERGLw&BBOX=0%2C-100%2C90%2C180&LABEL=OMI-Aura_L2G-OMTO3G_2005m0101_v003-2012m0404t152005.SUB.he5&SHORTNAME=OMTO3G&SERVICE=SUBSET_HE5&VERSION=1.02&DATASET_VERSION=003&VARIABLES=ColumnAmountO3"; I greatly appreciate you efforts! Irina
Re: [Bug-wget] Wget tests
On Mon, 15 Aug 2016 15:06:52 -0400
wor...@alum.mit.edu (Dale R. Worley) wrote:
> Can someone give me a hint how the wget tests work? The test
> directories seem to contain no high-level documentation. As far as I
> can tell, the pairs of files *.{trs,log} either are or correspond to the
> various tests, but I can't find the file(s) that specify what the test
> invocations of wget are, nor what files the test HTTP server sees.
>
> Thanks,
>
> Dale
>
I can tell you what worked for me to run the tests (take a look at the file
INSTALL).
$ wget -c http://ftp.gnu.org/gnu/wget/wget-1.18.tar.xz
$ tar -xf wget-1.18.tar.xz
$ cd wget-1.18
$ ./configure [your options here]
$ make check
to run some of the tests:
$ cd tests
$ make check
- or -
$ git clone git://git.savannah.gnu.org/wget.git
$ cd wget
$ ./bootstrap
$ ./configure [your options here]
$ make check
Good luck,
Matthew
--
Matthew White
pgpTxqF2Uyga3.pgp
Description: PGP signature
[Bug-wget] Wget tests
Can someone give me a hint how the wget tests work? The test
directories seem to contain no high-level documentation. As far as I
can tell, the pairs of files *.{trs,log} either are or correspond to the
various tests, but I can't find the file(s) that specify what the test
invocations of wget are, nor what files the test HTTP server sees.
Thanks,
Dale
Re: [Bug-wget] Wget - acess list bypass / race condition PoC
On Montag, 15. August 2016 10:02:55 CEST moparisthebest wrote: > Hello, > > I find it extremely hard to call this a wget vulnerability when SO many > other things are wrong with that 'vulnerable code' implementation it > isn't even funny: > > 1. The image_importer.php script takes a single argument, why would it > download with the recursive switch turned on? Isn't that clearly a bug > in the php script? Has a php script like this that downloads all files > from a website of a particular extension ever been observed in the wild? > > 2. A *well* configured server would have a whitelist of .php files it > will execute, making it immune to this. A *decently* configured server > would always at a minimum make sure they don't execute code in > directories with user provided uploads in them. So it's additionally a > bug in the server configuration. (incidentally every php package I've > downloaded has at minimum a .htaccess in upload directories to prevent > this kind of thing with apache) > > It seems to me like there has always been plenty of ways to shoot > yourself in the foot with PHP, and this is just another iteration on a > theme. Hi, this is absolutely true and your points were the first things that came to my mind when reading the original post. But there is also non-obvious wget behavior in creating those (temp) files in the filesystem. And there is also a long history of attack vectors introduced by temp files as well. Today the maintainers discussed a few possible fixes, all with pros and cons. I would like to list them here, in case someone likes to comment: 1. Rewrite code to keep temp files in memory. Too complex, needs a redesign of wget. And has been done for wget2... 2. Add a harmless extension to the file names. Possible name collision with wanted files. Possible name length issues, have to be worked around. 3. Using file mode 0 (no flags at all). Short vulnerability when changing modes to write/read the data. 4. Using O_TMPFILE for open(). Just for Linux, not for every filesystem available. 5. Using mkostemp(). Possible name collision with wanted files (which would be unexpectedly named as *.1 in case of a collision). At least the chance for a collision seems very low. Any thoughts or other ideas ? Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] Wget - acess list bypass / race condition PoC
Hello, I find it extremely hard to call this a wget vulnerability when SO many other things are wrong with that 'vulnerable code' implementation it isn't even funny: 1. The image_importer.php script takes a single argument, why would it download with the recursive switch turned on? Isn't that clearly a bug in the php script? Has a php script like this that downloads all files from a website of a particular extension ever been observed in the wild? 2. A *well* configured server would have a whitelist of .php files it will execute, making it immune to this. A *decently* configured server would always at a minimum make sure they don't execute code in directories with user provided uploads in them. So it's additionally a bug in the server configuration. (incidentally every php package I've downloaded has at minimum a .htaccess in upload directories to prevent this kind of thing with apache) It seems to me like there has always been plenty of ways to shoot yourself in the foot with PHP, and this is just another iteration on a theme. Just my 2 cents, Thanks!
