Salvatore Bonaccorso | 25 Jun 07:12 2016
Picon

Linux CVE-2016-1237: nfsd: any user can set a file's ACL over NFS and grant access to it

Hi

David Sinquin reported that anyone may be able to grant themselves
permissions to a file by setting the ACL. nfsd did not check
permissions when setting ACLs.

CVE-2016-1237 was assigned by the Debian security team for this issue
were David Singuin initially reported the issue.

The permission checks and inode locking were lost in a refactoring
with commit 4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 which was in
v3.14-rc1.

The issue is fixed with commit
999653786df6954a31044528ac3f7a5dadca08f4 in Linus' tree.

Introduced in: https://git.kernel.org/linus/4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 (v3.14-rc1)

Prerequisite: https://git.kernel.org/linus/485e71e8fb6356c08c7fc6bcce4bf02c9a9a663f 

Fixed by https://git.kernel.org/linus/999653786df6954a31044528ac3f7a5dadca08f4 

Regards,
Salvatore
redrain root | 25 Jun 06:18 2016
Picon
Gravatar

Ruby:HTTP Header injection in 'net/http'

TIMELINE
rootredrain submitted a report to Ruby.

show raw
Jun 22nd

Hi,

I would like to report a HTTP Header injection vulnerability in
'net/http' that allows attackers to inject arbitrary headers in
request even create a new evil request.

PoC

require 'net/http'
http = Net::HTTP.new('192.168.30.214','80')
res = http.get("/r.php HTTP/1.1\r\nx-injection: memeda")

Example

Server Code:

#!/usr/bin/env ruby
require 'sinatra'
require 'uri'
require 'net/http'

get '/' do
  'hello world'
end
(Continue reading)

Jesse Hertz | 24 Jun 20:53 2016

Linux CVE-2016-4997 (local privilege escalation) and CVE-2016-4998 (out of bounds memory access)

Hi All,

As part of a kernel fuzzing project by myself and my colleague Tim Newsham, we are disclosing two vulnerabilities which have been assigned CVEs. Full details of the fuzzing project (with analysis of the vulnerabilities) will be released next week. 

These issues are fixed in the following commits

And have now been integrated into stable kernel releases: 3.14.73, 4.4.14, and 4.6.3. 

Theses issues occurs in the same codepaths as, but are distinct from, a similar vulnerability: CVE-2016-3134 (https://bugs.chromium.org/p/project-zero/issues/detail?id=758). 

#########

CVE-2016-4997: Corrupted offset allows for arbitrary decrements in compat IPT_SO_SET_REPLACE setsockopt

Risk: High

Impact: Kernel memory corruption, leading to elevation of privileges or kernel code execution. This occurs in a compat_setsockopt() call that is normally restricted to root, however, Linux 3/4 kernels that support user and network namespaces can allow an unprivileged user to trigger this functionality. This is exploitable from inside a container. 

##########

CVE-2016-4998: Out of bounds reads when processing IPT_SO_SET_REPLACE setsockopt

Risk: Medium

Impact: Out of bounds heap memory access, leading to a Denial of Service (or possibly heap disclosure or further impact). This occurs in a setsockopt() call that is normally restricted to root, however, Linux 3/4 kernels that support user and network namespaces can allow an unprivileged user to trigger this functionality. This is exploitable from inside a container. 

##########


Best,
-jh
Alvaro Hoyos | 24 Jun 19:14 2016

[CVE-2016-5697] signature wrapping attack vulnerability in ruby-saml prior to version 1.3.0

Overview:
Ruby-saml prior to version 1.3.0 is vulnerable to an XML signature wrapping
attack. Ruby-saml users must update to 1.3.0 version which implements 3
extra validations to mitigate this kind of attack.

Overall CVSS Score 6.1

Fix: Add extra validations to prevent Signature wrapping attacks [1]

[1] https://github.com/onelogin/ruby-saml

alvaro j hoyos | chief information security officer |
alvaro.hoyos@... | +1 415.653.1893 | skype: alvaroonelogin
Brandon Perry | 24 Jun 15:54 2016
Picon
Gravatar

libical 0.47 SEGV on unknown address

Hello lists

Attached is a test case for causing a crash in libical 0.47 (shipped with Thunderbird) and this was also tested against 1.0 (various versions shipped with various email clients).


=================================================================
==24662==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x0000004fbb80 bp 0x7ffd68d966f0 sp 0x7ffd68d96520 T0)
    #0 0x4fbb7f in icalproperty_new_clone (/root/tmp/new_parse/parse_string047_asan+0x4fbb7f)
    #1 0x4f44e6 in icalparser_add_line (/root/tmp/new_parse/parse_string047_asan+0x4f44e6)
    #2 0x4efabe in icalparser_parse (/root/tmp/new_parse/parse_string047_asan+0x4efabe)
    #3 0x4f9c1f in icalparser_parse_string (/root/tmp/new_parse/parse_string047_asan+0x4f9c1f)
    #4 0x4eb7ef in main (/root/tmp/new_parse/parse_string047_asan+0x4eb7ef)
    #5 0x7fb657683a3f in __libc_start_main /build/glibc-ryFjv0/glibc-2.21/csu/libc-start.c:289
    #6 0x444ae8 in _start (/root/tmp/new_parse/parse_string047_asan+0x444ae8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 icalproperty_new_clone
==24662==ABORTING



I am posting this to Full Disclosure/OSS instead of reporting it because I have opened a handful of libical bugs in the Mozilla bug tracker, alerted security-4eJtQOnFJqFAfugRpC6u6w@public.gmane.org, and worked to show how and where to reproduce the bugs in Thunderbird, but Mozilla hasn’t shown any care at all about the bugs. Perhaps if I give a sample to the community of the bugs in the bug reports, Mozilla will take the bug reports more seriously. This bug attached had not been reported yet.
Attachment (segv.ics.bug): application/octet-stream, 8183 bytes


While list members likely will not have access to these bugs, I am listing them here in case someone on the list can make something happen.

https://bugzilla.mozilla.org/show_bug.cgi?id=1275400 (Opened a month ago. After Tyson reproed the bug in libical, no responses).

The following three bugs are distinct heap over-reads in libical (tested against libical 0.47 and 1.0) which have had little to no reception by Mozilla.


My roommate mentioned Thunderbird being a second-class citizen in the Mozilla world, so if this is the case, this should be made explicit in regards to bug bounty expectations. 
Michael Ellerman | 24 Jun 09:23 2016
Picon
Gravatar

CVE Request: Linux: powerpc/tm: Always reclaim in start_thread() for exec() class syscalls

Hi,

We've found an issue in the handling of Transactional Memory on powerpc
systems. An unprivileged local user can crash the kernel by starting a
transaction, suspending it, and then calling any of the exec() class system
calls.

More info:
 https://patchwork.ozlabs.org/patch/636776/
 https://patchwork.ozlabs.org/patch/636774/ (test case)

Could you please allocate a CVE for this?

cheers
Kirill Zaitsev | 23 Jun 19:42 2016

RCE vulnerability in Openstack Murano using insecure YAML tags (CVE-2016-4972)

============================================================== RCE vulnerability in Openstack Murano using insecure YAML tags ============================================================== :Date: June 23, 2016 :CVE: CVE-2016-4972 Affects ~~~~~~~ - Murano: <=2015.1.1; <=1.0.2; ==2.0.0 - Murano-dashboard: <=2015.1.1; <=1.0.2; ==2.0.0 - Python-muranoclient: <=0.7.2; >=0.8.0<=0.8.4 Description ~~~~~~~~~~~ Kirill Zaitsev from Mirantis reported a vulnerability in OpenStack Murano applications processing. Using extended YAML tags in Murano application YAML files, an attacker can perform a Remote Code Execution attack. Vulnerability has been verified in all currently supported branches. Further examination of code suggest, that it is also present in kilo and juno versions of murano. Patches ~~~~~~~ - https://review.openstack.org/#/c/333444/ (Liberty) - https://review.openstack.org/#/c/333425/ (Liberty) - https://review.openstack.org/#/c/333432/ (Liberty) - https://review.openstack.org/#/c/333443/ (Mitaka) - https://review.openstack.org/#/c/333424/ (Mitaka) - https://review.openstack.org/#/c/333439/ (Mitaka) - https://review.openstack.org/#/c/333423/ (Newton) - https://review.openstack.org/#/c/333440/ (Newton) - https://review.openstack.org/#/c/333428/ (Newton) Credits ~~~~~~~ - Kirill Zaitsev from Mirantis (CVE-2016-4972) References ~~~~~~~~~~ - https://bugs.launchpad.net/python-muranoclient/+bug/1586078 - https://bugs.launchpad.net/murano/+bug/1586079 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4972
Notes ~~~~~ - Fixes for this bug are going to be included in the upcoming releases of murano 1.0.3(liberty), 2.0.1(mitaka), 3.0.0(newton) and python-muranoclient 0.7.3(liberty), 0.8.5(mitaka), 0.9.0(newton) -- Kirill Zaitsev Murano Project Technical Lead
Salvatore Bonaccorso | 23 Jun 19:12 2016
Picon

CVE Requests: WordPress: 4.5.3 maintenance and security release: several issues

Hi

WordPress issued version 4.5.3 a maintenace and security release. The
advisory mentions several issues fixed:

https://wordpress.org/news/2016/06/wordpress-4-5-3/

WordPress versions 4.5.2 and earlier are affected by several security
issues:

 - redirect bypass in the customizer, reported by Yassine Aboukir;

 - two different XSS problems via attachment names, reported by Jouko
   Pynnönen and Divyesh Prajapati;

 - revision history information disclosure, reported independently by
   John Blackbourn from the WordPress security team and by Dan Moen from
   the Wordfence Research Team;

 - oEmbed denial of service reported by Jennifer Dodd from Automattic;

 - unauthorized category removal from a post, reported by David Herrera
   from Alley Interactive;

 - password change via stolen cookie, reported by Michael Adams from the
   WordPress security team;

 - and some less secure sanitize_file_name edge cases reported by Peter
   Westwood of the WordPress security team.

(I wrapped the advisory text in the various separate items).

Could you assign CVE identifier as needed for the above issues fixed
with the Wordpress 4.5.3 release?

Regards,
Salvatore

Hanno Böck | 23 Jun 15:58 2016
Picon
Gravatar

Out of bounds read and signed integer overflow in libarchive

https://blog.fuzzing-project.org/48-Out-of-bounds-read-and-signed-integer-overflow-in-libarchive.html

https://groups.google.com/forum/#!topic/libarchive-discuss/sui01WaM3ic
I recently wrote about a large number of bugs and potential security
issues in libarchive. The release 3.2.0 missed one fix for an out of
bounds read in the rar parser. Also I discovered one additional signed
integer overflow issue with ubsan. Both issues are now fixed in
libarchive 3.2.1. All issues were discovered with the help of american
fuzzy lop.

https://github.com/libarchive/libarchive/issues/521
Out of bounds heap read in RAR parser
http://libarchive.github.io/google-code/issue-413/comment-0/bsdtar-invalid-read.rar
Sample rar file
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8934
CVE-2015-8934

https://github.com/libarchive/libarchive/issues/717#event-697151157
Signed integer overflow in ISO parser
https://github.com/libarchive/libarchive/files/321672/libarchive-signed-int-overflow.zip
Sample ISO file

http://blog.talosintel.com/2016/06/the-poisoned-archives.html
Also a couple of other security issues in libarchive were found by
Cisco.

With the release of version 3.2.1 I consider libarchive to be
reasonably robust against fuzzing. I've tested all supported file
formats and fuzzed each one with afl/asan for at least one day. Of
course that doesn't mean that no security issues are left - but the
easy to find ones should be wiped out.

--

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@...
GPG: BBB51E42
Lior Kaplan | 23 Jun 09:58 2016
Picon

CVE for PHP 5.5.37 issues

Hi,

PHP 5.5.37 is near its release, please review these following issues for
CVE:

GD:
  . Fixed bug #72339 (Integer Overflow in _gd2GetHeader() resulting in
    heap overflow). (Pierre)

https://bugs.php.net/bug.php?id=72339
http://git.php.net/?p=php-src.git;a=commitdiff;h=7722455726bec8c53458a32851d2a87982cf0eac

GD:
  . Fixed bug #72446 (Integer Overflow in gdImagePaletteToTrueColor()
resulting
    in heap overflow). (Pierre)

https://bugs.php.net/bug.php?id=72446
http://git.php.net/?p=php-src.git;a=commitdiff;h=c395c6e5d7e8df37a21265ff76e48fe75ceb5ae6

- mbstring:
   . Fixed bug #72402 (_php_mb_regex_ereg_replace_exec - double free).
(Stas)

https://bugs.php.net/bug.php?id=72402
http://git.php.net/?p=php-src.git;a=commitdiff;h=5b597a2e5b28e2d5a52fc1be13f425f08f47cb62

- mcrypt:
   . Fixed bug #72455 (Heap Overflow due to integer overflows). (Stas)

https://bugs.php.net/bug.php?id=72455
http://git.php.net/?p=php-src.git;a=commitdiff;h=6c5211a0cef0cc2854eaa387e0eb036e012904d0

- SPL:
  . Fixed bug #72262 (int/size_t confusion in SplFileObject::fread). (Stas)

https://bugs.php.net/bug.php?id=72262
http://git.php.net/?p=php-src.git;a=commitdiff;h=7245bff300d3fa8bacbef7897ff080a6f1c23eba

- SPL:
  . Fixed bug #72433 (Use After Free Vulnerability in PHP's GC algorithm and
    unserialize). (Dmitry)

https://bugs.php.net/bug.php?id=72433
http://git.php.net/?p=php-src.git;a=commitdiff;h=3f627e580acfdaf0595ae3b115b8bec677f203ee

- WDDX:
  . Fixed bug #72340 (Double Free Courruption in wddx_deserialize). (Stas)

https://bugs.php.net/bug.php?id=72340
http://git.php.net/?p=php-src.git;a=commitdiff;h=a44c89e8af7c2410f4bfc5e097be2a5d0639a60c

- zip:
  . Fixed bug #72434 (ZipArchive class Use After Free Vulnerability in
PHP's GC
    algorithm and unserialize). (Dmitry)

https://bugs.php.net/bug.php?id=72434
http://git.php.net/?p=php-src.git;a=commitdiff;h=f6aef68089221c5ea047d4a74224ee3deead99a6

Kaplan
Ibrahim el-sayed | 23 Jun 02:47 2016
Picon

Fwd: out-of-bounds read in MagickCore/property.c:1396 could lead to memory leak/ Integer overflow read to RCE

Hi Mitre CVE assignment team,
I have submitted the following two bugs to ImageMagick. Both got acknowledged and fixed in the following patch
I would be so glad if you can issue me CVEs for them

Regards
Ibrahim 



Begin forwarded message:

Subject: Integer overflow that lead to RCE
Date: June 21, 2016 at 6:58:20 PM GMT+1

Hi ImageMagick security team,
I was fuzzing imagemagick with AFL and I think I found an integer overflow that might lead to remote code execution. 

The vulnerability exists in the following line 

components=(ssize_t) ReadProfileLong(endian,q+4); << I think component should be size_t
number_bytes=(size_t) components*format_bytes[format];
I think components variable is upgraded to integer in this line.
component is stored in edx in the assembly and before the multplication the following instructions are executed

0000000000475D3E movsxd  rax, edx ;edx contains components variable and it is using movsx (move signed extended which I think the main cause of the vulnerability). if The value of components anything above 0xC0000000 the sign extension will be 1 and rax will be 0xFFFFFFFFC0000000. The main problem of this I think because ssize_t which covers the -1 value 
0000000000475D41 movsxd  rcx, ds:SyncExifProfile_format_bytes[rcx*4] 
0000000000475D49 imul    rcx, rax
0000000000475D4D cmp     rcx, rax ;This is unsigned comparison because of jump below (jl) 
0000000000475D50 jl      exit
    
After the multiplication rcx contains number_bytes as (integer 64bit) and not size_t

In the if condition, the PoC takes the else part. 


2036: if ((size_t) (offset+number_bytes) > length)
An integer oveflow occurs in this comparison because number_bytes is a very large number like (0xFFFFFFFFFFFFFF87) and when we add offset to it which we control we can overflow and the result is < length so we pass this if condition. 
2040: p=(unsigned char *) (exif+offset);
At 2040 the offset value is the value we are controlling and can range between 0x7B-0x40000001 as illustrated in the PoC

pointer p is used later in to write data to it. 
The PoC goes into the switch statement and then choose case 0x011b. And then it write 4 bytes on line
2052: (void) WriteProfileLong(endian,(size_t) (image->resolution.y+0.5),p);
Needless to day we can control image->resolution.y
Also if we took another path in the switch statement we can also control 
image->orientation or image->units which are the values written to the pointer we can control.


You can find attached two Proof of Concept files. 
PoC1:
This PoC will set number_bytes = 0xFFFFFF87  ==>> will be sign extended to 0xFFFFFFFFFFFFFFFF87 and offset = 0x7B.
This PoC will basically write 4 null bytes into position exif+0x7B (offset)

PoC2: 
This PoC will set number_bytes = 0xC0000000 which will be sign extended to 0xFFFFFFFFC0000000 and offset = 0x40000001
This will write 4 null bytes in position exif+0x40000001 (offset). 

PoC2 will cause a seg-fault because usually this memory address (exif+0x40000001) might not be mapped or doesn't have the correct permission to write to


Regards
Ibrahim M. El-Sayed
Security Engineer
<at> ibrahim_mosaad





Begin forwarded message:

Subject: out-of-bounds read in MagickCore/property.c:1396 could lead to memory leak
Date: June 21, 2016 at 3:04:23 PM GMT+1

Hi ImageMagick Security Team,

I think I have found a security bug. The bug was found while fuzzing ImageMagick with afl-fuzz

command: magick identify PoC.jpg
The vulnerability could lead to information leakage because the pointer is used later to read data from the memory


MagickCore/property.c:1401 format=(size_t) ReadPropertyUnsignedShort(endian,q+2);
MagickCore/property.c:1404 components=(ssize_t) ReadPropertySignedLong(endian,q+4);

The code basically reads the number of entries inside directory object in an image
MagickCore/property.c:1382 number_entries=(size_t) ReadPropertyUnsignedShort(endian,directory);

By manipulating bytes at position 0x76 and 0x77 in the PoC image, we can control number_entries variable which is used to in the loop. By controlling number_entries we can partially control q
MagickCore/property.c:1396 q=(unsigned char *) (directory+(12*entry)+2);

In the previous line we control the value of "entry". As a result, we can partially control q which can be used later to read arbitrary data from the process of ImageMagick.

PoC image: https://www.ibrahim-elsayed.com/uploads/PoC_imagemagick_1.jpg

[backtrace]
storm <at> storm ~/f/f/f/crashes> gdb -q magick core.magick.14585
Reading symbols from magick...done.
[New LWP 14585]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `magick identify PoC.jpg'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f110bac6c37 in __GI_raise (sig=sig <at> entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f110bac6c37 in __GI_raise (sig=sig <at> entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f110baca028 in __GI_abort () at abort.c:89
#2 0x0000000000421b5b in MagickSignalHandler (signal_number=6) at MagickCore/magick.c:1310
#3 <signal handler called>
#4 0x00007f110bac6c37 in __GI_raise (sig=sig <at> entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#5 0x00007f110baca028 in __GI_abort () at abort.c:89
#6 0x0000000000421b5b in MagickSignalHandler (signal_number=11) at MagickCore/magick.c:1310
#7 <signal handler called>
#8 ReadPropertySignedLong (buffer=0x293c000 <error: Cannot access memory at address 0x293c000>,
    endian=LSBEndian) at MagickCore/property.c:745
#9 GetEXIFProperty (image=image <at> entry=0x291aff0, property=property <at> entry=0x7ffe5d180910 "exif:*",
    exception=exception <at> entry=0x28e7f10) at MagickCore/property.c:1404
#10 0x000000000043e4d8 in GetImageProperty (image=image <at> entry=0x291aff0,
    property=property <at> entry=0x7ffe5d180910 "exif:*", exception=exception <at> entry=0x28e7f10)
    at MagickCore/property.c:2197
#11 0x0000000000441d03 in SetImageProfileInternal (image=image <at> entry=0x291aff0,
    name=name <at> entry=0x7ffe5d181990 "exif", profile=profile <at> entry=0x28ffe30,
    recursive=recursive <at> entry=MagickFalse, exception=exception <at> entry=0x28e7f10) at MagickCore/profile.c:1671
#12 0x000000000044297a in SetImageProfile (image=image <at> entry=0x291aff0, name=name <at> entry=0x7ffe5d181990 "exif",
    profile=profile <at> entry=0x28ffe30, exception=exception <at> entry=0x28e7f10) at MagickCore/profile.c:1678
#13 0x000000000053c922 in ReadProfile (jpeg_info=<optimised out>) at coders/jpeg.c:738
#14 0x00007f1110464975 in ?? () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8
#15 0x00007f11104629ca in ?? () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8
#16 0x00007f111045cf57 in jpeg_consume_input () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8
#17 0x00007f111045d223 in jpeg_read_header () from /usr/lib/x86_64-linux-gnu/libjpeg.so.8
#18 0x000000000053d669 in ReadJPEGImage (image_info=0x28fa130, exception=0x28e7f10) at coders/jpeg.c:1101
#19 0x00000000005a06ee in ReadImage (image_info=image_info <at> entry=0x28f4b90,
    exception=exception <at> entry=0x28e7f10) at MagickCore/constitute.c:554
#20 0x0000000000677326 in ReadStream (image_info=image_info <at> entry=0x28f1910,
    stream=stream <at> entry=0x59ffb0 <PingStream>, exception=exception <at> entry=0x28e7f10) at MagickCore/stream.c:1012
#21 0x00000000005a0261 in PingImage (image_info=image_info <at> entry=0x28ee4f0,
---Type <return> to continue, or q <return> to quit---
    exception=exception <at> entry=0x28e7f10) at MagickCore/constitute.c:226
#22 0x00000000005a04ab in PingImages (image_info=image_info <at> entry=0x28ee4f0,
    filename=filename <at> entry=0x28e7f50 "PoC.jpg", exception=exception <at> entry=0x28e7f10)
    at MagickCore/constitute.c:326
#23 0x00000000006f2741 in IdentifyImageCommand (image_info=0x28eb2c0, image_info <at> entry=0x28e8090,
    argc=argc <at> entry=2, argv=0x28e6490, argv <at> entry=0x7ffe5d18e4b0, metadata=metadata <at> entry=0x7ffe5d18c150,
    exception=exception <at> entry=0x28e7f10) at MagickWand/identify.c:319
#24 0x000000000071a274 in MagickCommandGenesis (image_info=image_info <at> entry=0x28e8090,
    command=command <at> entry=0x6f2180 <IdentifyImageCommand>, argc=2, argv=argv <at> entry=0x7ffe5d18e4b0,
    metadata=0x7ffe5d18d208, exception=exception <at> entry=0x28e7f10) at MagickWand/mogrify.c:183
#25 0x0000000000411f11 in MagickMain (argc=2, argv=0x7ffe5d18e4b0) at utilities/magick.c:250
#26 0x00007f110bab1f45 in __libc_start_main (main=0x40ec10 <main>, argc=3, argv=0x7ffe5d18e4a8,
    init=<optimised out>, fini=<optimised out>, rtld_fini=<optimised out>, stack_end=0x7ffe5d18e498)
    at libc-start.c:287
#27 0x0000000000411af5 in _start ()



Gmane