bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] bug / security concern


From: A.K. Zidani
Subject: Re: [Bug-wget] bug / security concern
Date: Tue, 15 Oct 2019 12:07:44 +0200

Hi Tim,

I could try that as well but this is the version that ships with Ubuntu on
Windows 10.
bear in mind this is not a wget for Windows, it's a native linux binary.
see this for more info: https://itsfoss.com/install-bash-on-windows/

I've submitted a security bug to that mailing list.
Please let me know if I can assist you further with testing this on newer
versions.






On Tue, 15 Oct 2019 at 12:00, Tim Rühsen <address@hidden> wrote:

> Hi,
>
> thanks for the report. Is that still an issue on a recent version of
> Wget ? The version 1.17.1 you are using is very outdated.
>
> We don't directly support windows binaries, but here is an unofficial
> website that provides for binary downloads:
>
> https://eternallybored.org/misc/wget/
>
> If you find possible security issues, please do not make them public by
> writing to this mailing list. Instead open an issue at
>   https://savannah.gnu.org/bugs/?func=additem&group=wget
> and set 'Privacy' to 'private'.
>
> Regards, Tim
>
> On 10/14/19 8:15 PM, A.K. Zidani wrote:
> > Hello there,
> >
> > I'm a security researcher and I think I found something interesting when
> > using wget to download a file under Windows's BASH environment.
> >
> > here is a quick poc I created:
> > https://addaxsoft.com/poc/AAAAAAAAA%bb%e4%b8%ad%e7AAAAAAAAAAAAAAAA
> > when you wget that file; wget will crash at:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > __memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:161
> >
> >    0x00007ffffe202ae6 <+374>:   sub    rax,rdx
> >    0x00007ffffe202ae9 <+377>:   vzeroupper
> >    0x00007ffffe202aec <+380>:   ret
> >    0x00007ffffe202aed <+381>:   nop    DWORD PTR [rax]
> >    0x00007ffffe202af0 <+384>:   sub    rcx,0xffffffffffffff80
> >    0x00007ffffe202af4 <+388>:   vmovd  eax,xmm0
> > => 0x00007ffffe202af8 <+392>:   rep stos BYTE PTR es:[rdi],al
> >    0x00007ffffe202afa <+394>:   mov    rax,rsi
> >    0x00007ffffe202afd <+397>:   sub    rax,rdx
> >    0x00007ffffe202b00 <+400>:   vzeroupper
> >    0x00007ffffe202b03 <+403>:   ret
> >
> > registers:
> > (gdb) info registers
> > rax            0x20202020       538976288
> > rbx            0xffffffffffffffff       -1
> > rcx            0xffffffffffff5387       -44153
> > rdx            0xffffffffffffffff       -1
> > rsi            0x84b1387        139137927
> > rdi            0x84bc000        139182080
> > rbp            0x84b1140        0x84b1140
> > rsp            0x7ffffffed558   0x7ffffffed558
> > r8             0x0      0
> > r9             0x1      1
> > r10            0x7ffffffed4a8   140737488278696
> > r11            0x8279880        136812672
> > r12            0x7      7
> > r13            0x7      7
> > r14            0x82798f0        136812784
> > r15            0x84b1388        139137928
> > rip            0x7ffffe202af8   0x7ffffe202af8 <__memset_avx2+392>
> > eflags         0x10287  [ CF PF SF IF RF ]
> > cs             0x33     51
> > ss             0x2b     43
> > ds             0x0      0
> > es             0x0      0
> > fs             0x0      0
> > gs             0x0      0
> >
> > rdi is accessing inaccessible memory which the cause of the crash:
> > (gdb) x $rdi
> > 0x84bc000:      Cannot access memory at address 0x84bc000
> >
> > here is my wget -V output:
> > root@PC:~# wget -V
> > GNU Wget 1.17.1 built on linux-gnu.
> >
> > +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls +ntlm
> > +opie -psl +ssl/openssl
> >
> > Wgetrc:
> >     /etc/wgetrc (system)
> > Locale:
> >     /usr/share/locale
> > Compile:
> >     gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
> >     -DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib
> >     -I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include
> >     -DHAVE_LIBSSL -DNDEBUG -g -O2 -fPIE -fstack-protector-strong
> >     -Wformat -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64
> >     -g -Wall
> > Link:
> >     gcc -DHAVE_LIBSSL -DNDEBUG -g -O2 -fPIE -fstack-protector-strong
> >     -Wformat -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64
> >     -g -Wall -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro
> >     -Wl,-z,now -L/usr/lib -lpcre -luuid -lssl -lcrypto -lz -lidn
> >     ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a
> >
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > Licence GPLv3+: GNU GPL version 3 or later
> > <http://www.gnu.org/licenses/gpl.html>.
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> >
> > Originally written by Hrvoje Niksic <address@hidden>.
> > Please send bug reports and questions to <address@hidden>.
> >
> >
> >
> >
> >
> > I didn't look into this further, but potentially I can have a memory
> write
> > if I get control of rdi and rax at some point in the code path, which may
> > lead to code execution as well.
> >
> > NOTE: this only crashes wget running in bash in a Windows environment.
> > not sure if this is the same as CVE-2019-5953, but I would like to
> > investigate further.
> >
> >
> >
> >
>
>

-- 
// A.K. Zidani ☁ imAK.xyz <http://www.imak.xyz/> 👔 linkedin.com/azidani
<https://www.linkedin.com/in/azidani>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]