Hi,
Eli Zaretskii writes:
>> #else /* def __VMS */
>> - *fp = fopen (hs->local_file, "wb");
>> + if (opt.delete_after
>> +|| opt.spider /* opt.recursive is implicitely true */
>> +|| !acceptable (hs->local_file))
>> +{
>> + *fp
couldn't you just use whatever secure mkstmp is appropriate for the
language wget is written in
http://rosettacode.org/wiki/Secure_temporary_file
so much easier and secure then faffing about.
On Wed, Aug 17, 2016 at 7:40 AM, Dawid Golunski
wrote:
> Random file name + .part extension on temporar
Hi Eli,
Eli Zaretskii writes:
>> From: Giuseppe Scrivano
>> Date: Sun, 21 Aug 2016 15:26:58 +0200
>> Cc: "bug-wget@gnu.org" ,
>> Dawid Golunski ,
>> "kseifr...@redhat.com"
>>
>> #else /* def __VMS */
>> - *fp = fopen (hs->local_file, "wb");
>> + if (opt.delete_aft
> From: Giuseppe Scrivano
> Date: Sun, 21 Aug 2016 15:26:58 +0200
> Cc: "bug-wget@gnu.org" ,
> Dawid Golunski ,
> "kseifr...@redhat.com"
>
> #else /* def __VMS */
> - *fp = fopen (hs->local_file, "wb");
> + if (opt.delete_after
> +|| opt.spider /* opt.r
Hi,
"Misra, Deapesh" writes:
> Yes - I whole heartedly agree with the following:
>
>>
>> To cite myself :)
>> "But there is also non-obvious wget behavior in creating those (temp) files
>> in
>> the filesystem."
>>
>> The Wget docs just don't make clear that these files come into existence f
Yes - I whole heartedly agree with the following:
>
> To cite myself :)
> "But there is also non-obvious wget behavior in creating those (temp) files
> in
> the filesystem."
>
> The Wget docs just don't make clear that these files come into existence for
> a
> while. Of course we could amend
On Donnerstag, 18. August 2016 15:34:12 CEST Giuseppe Scrivano wrote:
> Hi,
>
> Tim Rühsen writes:
> > Please review / test this patch.
> >
> > Please check the 'Reported-by' in the commit message and if you got a CVE
> > number, please report for inclusion into the commit message (and/or the
>
Hi,
Tim Rühsen writes:
> Please review / test this patch.
>
> Please check the 'Reported-by' in the commit message and if you got a CVE
> number, please report for inclusion into the commit message (and/or the code).
>
> Regards, Tim
>
> On Mittwoch, 17. August 2016 10:40:35 CEST Dawid Golunski
CVE-ID team, could you please let us know a CVE-ID number we could use
for the GNU Wget vulnerability described in this thread ?
Thanks
On Wed, Aug 17, 2016 at 7:03 PM, Dawid Golunski wrote:
> Hi Tim,
>
> Thanks for this. The filename generation with temporary name in it looks
> good.
> As for
Hi Tim,
Thanks for this. The filename generation with temporary name in it looks good.
As for the credit, I discovered this vulnerability and passed it on to
VeriSign, so I'd appreciate it if you could add 1 more credit in the
patch / bug announcement as:
Discovered by: Dawid Golunski (http://le
Please review / test this patch.
Please check the 'Reported-by' in the commit message and if you got a CVE
number, please report for inclusion into the commit message (and/or the code).
Regards, Tim
On Mittwoch, 17. August 2016 10:40:35 CEST Dawid Golunski wrote:
> Random file name + .part exten
Random file name + .part extension on temporary files would already be
good improvement (even if still stored within the same directory) and
help prevent the exploitation.
Thanks.
On Wed, Aug 17, 2016 at 9:22 AM, Tim Rühsen wrote:
> On Mittwoch, 17. August 2016 13:37:33 CEST Ander Juaristi wrote
On Mittwoch, 17. August 2016 13:37:33 CEST Ander Juaristi wrote:
> I was thinking we could rename php extensions to phps, but it's all the
> same thing in the end, and even better, since the former applies to any
> kind of file and I've seen some broken servers that actually run phps files.
>
> So
I was thinking we could rename php extensions to phps, but it's all the
same thing in the end, and even better, since the former applies to any
kind of file and I've seen some broken servers that actually run phps files.
So, this is what I would do:
1. Write temporary files with 600 perms, an
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 argume
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 cl
Hi,
I'm attaching the PoC to this email.
As you can see, this scenario doesn't require attacker to have access
to the filesystem (as was suggested earlier in the thread on
oss-security group) ,and attacker is able to supply his URL as per
'import from URL' functionality which is common in many ap
17 matches
Mail list logo
