A type confusion vulnerability can occur when manipulating JavaScript objects due to issues in Array.pop. This can allow for an exploitable crash. We are aware of targeted attacks in the wild abusing this flaw. This vulnerability affects Firefox ESR < 60.7.1, Firefox < 67.0.3, and Thunderbird < 60.7.2.

**Mozilla Foundation Security Advisory 2019-20**

Announced

June 20, 2019

Impact

high

Products

Thunderbird

Fixed in

*   Thunderbird 60.7.2

_In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts._

**#CVE-2019-11707: Type confusion in Array.pop**

Reporter

Samuel Groß of Google Project Zero, Coinbase Security

Impact

critical

**Description**

A type confusion vulnerability can occur when manipulating JavaScript objects due to issues in Array.pop. This can allow for an exploitable crash. We are aware of targeted attacks in the wild abusing this flaw.

**References**

*   Bug 1544386

**#CVE-2019-11708: sandbox escape using Prompt:Open**

Reporter

Coinbase Security

Impact

high

**Description**

Insufficient vetting of parameters passed with the Prompt:Open IPC message between child and parent processes can result in the non-sandboxed parent process opening web content chosen by a compromised child process. When combined with additional vulnerabilities this could result in executing arbitrary code on the user's computer.

**References**

*   Bug 1559858

CVE-2019-11707: Security vulnerabilities fixed in Thunderbird 60.7.2

moinejf abcm2ps 8.13.20 is affected by: Incorrect Access Control. The impact is: Allows attackers to cause a denial of service attack via a crafted file. The component is: front.c, function txt_add. The fixed version is: after commit commit 08aef597656d065e86075f3d53fda89765845eae.

https://drive.google.com/open?id=1Y2IbtEr9v4l4Ruie\_AY9BFJOHOGiDt7S

(gdb) set args POC4  
(gdb) r

abcm2ps-8.13.20 (2018-02-21)  
File POC4  
Line 14: Empty line in tune header - K:C added

Program received signal SIGSEGV, Segmentation fault.  
\_\_memcpy\_avx\_unaligned () at ../sysdeps/x86\_64/multiarch/memcpy-avx-unaligned.S:273  
273 ../sysdeps/x86\_64/multiarch/memcpy-avx-unaligned.S: No such file or directory.  
(gdb) bt  
#0 0x00007ffff69d51e3 in \_\_memcpy\_avx\_unaligned ()  
at ../sysdeps/x86\_64/multiarch/memcpy-avx-unaligned.S:273  
#1 0x00000000004e1b5b in txt\_add (\_\_len=18446744073709551615, \_\_src=0x827f3e, \_\_dest=)  
at /usr/include/x86\_64-linux-gnu/bits/string3.h:53  
#2 0x00000000004e1b5b in txt\_add (s=0x827f3e "", sz=-1) at front.c:117  
#3 0x00000000004e558a in frontend (s=,  
s@entry=0x827ea0 "X:Eƒ\\nB\\222\\nWV\\thf\\nf\\nI:tOB\\222\\nW:T@\\nW:\\nW:9 hf\\nf\\nI: OB\\222\\nW:\\t@EBhf\\nf\\nI: OB\\222\\n\\nW OB\\222\\nW:\\\\nB\\222\\nWV\\thf\\nf\\nI:tOB\\222\\nW:Tt\\nW:\\nW:9\\211hf\\nf\\nI: OB\\222\\nW:\\tOEBx\\nW:TthB\\222\\035W:x\\nW:\\nW:9thf\\nf\\nI: ", ftype=ftype@entry=0, fname=fname@entry=0x827f60 "POC4", linenum=31, linenum@entry=0) at front.c:882  
#4 0x000000000040b98d in treat\_file (fn=, ext=) at abcm2ps.c:239  
#5 0x00000000004084f9 in main (argc=0, argv=) at abcm2ps.c:1040

CVE-2019-1010069: access violation front.c:117 in txt_add(unsigned char *s, int sz) · Issue #18 · lewdlime/abcm2ps

There is an out-of-bounds read in Exiv2::MrwImage::readMetadata in mrwimage.cpp in Exiv2 through 0.27.2.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation 37 Commits 1 Checks 0 Files changed

**Conversation**

This commit places the basics for libFuzzer integration with one  
fuzzer which fuzzes the readMetadata function. The fuzzer is  
located at fuzz/read-metadata.

To add more fuzzers please add them to ./fuzz directory as  
described in the README.

Also a memory corruption bug is found using this fuzzer which  
might lead to additional bugs after fix is pushed.

Attached is the crash for the read-metadata.cpp fuzzer + screenshot of the backtrace.

I think this should also be given a CVE for a memory corruption vulnerability which affects programs that use the API to read bytes and not a file.

I'll be happy to contribute more fuzzers after this bug is fixed so it won't fail the other fuzzers.

Also, I'll be happy to contribute an integration to Fuzzit (I'm the CEO of the company) which will enable continuous fuzzing for the project for free as it's an open-source project. you can read also about systemd case study here @clanmills

Not sure who is the right person to review the PR. but CCing @kevinbackhouse as you merged a CVE bugfix lately.

Cheers,  
Yevgeny

Please could you include exact reproduction steps? What command line did you run this with?

Sure. here it is (clang >6.0 must be installed).

cd <exivdir\>
mkdir build
cd build
export CXX=clang++
export CC=clang
cmake .. -G "Unix Makefiles" "\-DCMAKE\_BUILD\_TYPE=Debug"  "\-DEXIV2\_BUILD\_FUZZ\_TESTS=ON"
make -j4
./bin/read-metadata

@yevgenypats: I cannot reproduce this on the command line:

    $ ./build/bin/exiv2 60588206-f9a14480-9d9e-11e9-981a-977e0741bb42.png 
    Exiv2 exception in print action for file 60588206-f9a14480-9d9e-11e9-981a-977e0741bb42.png:
    Failed to read image data
    

I also stepped through it in the debugger and all it does is throw an exception at mrwimage.cpp:123.

@kevinbackhouse Yes, because you tried to reproduce with exiv2 which is a bit different because it's reading from a file i.e using this api: ImageFactory::open(const std::string& path, bool useCurl) and not ImageFactory::open(const byte* data, size_t size) which is a bit different and thus not getting to the buggy function which is readMetadata.

try to reproduce by running the fuzzer with the testcase I attached ./bin/read-metadata <test_case>

This commit places the basics for libFuzzer integration with one
fuzzer which fuzzes the readMetadata function. The fuzzer is
located at fuzz/read-metadata.

To add more fuzzers please add them to ./fuzz directory as
described in the README.

Also a memory corruption bug is found using this fuzzer which
might lead to additional bugs after fix is pushed.

@kevinbackhouse Also I just push a review fix per @cryptomilk instructions so the compile line now is

mkdir build
cd build
cmake .. -G "Unix Makefiles" "\-DEXIV2\_BUILD\_FUZZ\_TESTS=ON"  "\-DCMAKE\_BUILD\_TYPE=AddressSanitizer"
make -j4
./bin/read-metadata

**D4N** requested changes Jul 4, 2019

Copy link

Member

** **D4N** left a comment**

Wow, thanks for this contribution!

However, by removing EXIV2_TEAM_USE_SANITIZERS you effectively crippled our CI pipeline to no longer run with ASAN + UBSAN. Unless this is fixed, this PR is a nogo. Fixing this will probably require some refactoring of the CMake code, please tell if you want to undertake this (we can take care of that too).

Hi Dan, Thanks:) I changed this per @cryptomilk request. I'm not sure I'm the right person to fix this as I'm not very familiar with it. I can change it backward and we can fix it in a different PR. So this pull request will only add the fuzzers. Also, would you like me to contribute another pull request so the fuzzers will run on a daily basis via Fuzzit integration? This way it may find new bugs and also catch If bugs are introduced again. Cheers, Yevgeny.

…

On Thu, Jul 4, 2019, 10:36 AM D4N \*\*\*@\*\*\*.\*\*\*> wrote: \*\*\*@\*\*\*.\*\*\*\* requested changes on this pull request. Wow, thanks for this contribution! However, by removing EXIV2\_TEAM\_USE\_SANITIZERS you effectively crippled our CI pipeline to no longer run with ASAN + UBSAN. Unless this is fixed, this PR is a nogo. Fixing this will probably require some refactoring of the CMake code, please tell if you want to undertake this (we can take care of that too). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#943?email\_source=notifications&email\_token=AD52CDS4ZZZEBEFYE7JUSETP5WZBPA5CNFSM4H5EZH42YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB5PU2ZI#pullrequestreview-257903973>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD52CDVPNEGL2WSEEC6Z5WDP5WZBPANCNFSM4H5EZH4Q\> .

Copy link

Member

****D4N** commented Jul 4, 2019**

Yevgeny Pats <notifications@github.com> writes:

Hi Dan, Thanks:) I changed this per @cryptomilk request. I'm not sure I'm the right person to fix this as I'm not very familiar with it. I can change it backward and we can fix it in a different PR. So this pull request will only add the fuzzers.

Could you push your previous state to another branch in your fork and post a link to that here?

Also, would you like me to contribute another pull request so the fuzzers will run on a daily basis via Fuzzit integration?

Once we merge this, why not? Before merging this, I see little benefit in that, beside cluttering my inbox ;-)

This way it may find new bugs and also catch If bugs are introduced again.

How is Fuzzit different from oss-fuzz, since I have the long term plan of getting exiv2 into oss-fuzz.

…

Cheers, Yevgeny. On Thu, Jul 4, 2019, 10:36 AM D4N \*\*\*@\*\*\*.\*\*\*> wrote: > \*\*\*@\*\*\*.\*\*\*\* requested changes on this pull request. > > Wow, thanks for this contribution! > > However, by removing EXIV2\_TEAM\_USE\_SANITIZERS you effectively crippled > our CI pipeline to no longer run with ASAN + UBSAN. Unless this is fixed, > this PR is a nogo. Fixing this will probably require some refactoring of > the CMake code, please tell if you want to undertake this (we can take care > of that too). > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#943?email\_source=notifications&email\_token=AD52CDS4ZZZEBEFYE7JUSETP5WZBPA5CNFSM4H5EZH42YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB5PU2ZI#pullrequestreview-257903973>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AD52CDVPNEGL2WSEEC6Z5WDP5WZBPANCNFSM4H5EZH4Q\> > . > -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #943 (comment)

Sounds good. Will do regarding the additional PR with the link. Fuzzit has some more features that OSS currently missing like running the tests on PRs as well ( https://fuzzit.dev/2019/06/20/continuous-fuzzing-systemd-case-study/) and a bit better user management IMHO. Essentially you can use both if you want. Systemd uses both and we are working with envoy/the Google team on an integration as well so they also will use both. In my opinion you can just use Fuzzit, essentially we are running the same fuzzers. I think teams that uses both usually started with OSS fuzz and then added Fuzzit after we launched. But that's up to you. So If it's fine with you once we merge I'll open an additional PR which should be pretty straightforward as we already have the foundations for the fuzzers themselves:)

…

On Thu, Jul 4, 2019, 3:57 PM D4N \*\*\*@\*\*\*.\*\*\*> wrote: Yevgeny Pats \*\*\*@\*\*\*.\*\*\*> writes: > Hi Dan, > > Thanks:) I changed this per @cryptomilk request. I'm not sure I'm the right > person to fix this as I'm not very familiar with it. I can change it > backward and we can fix it in a different PR. So this pull request will > only add the fuzzers. Could you push your previous state to another branch in your fork and post a link to that here? > > Also, would you like me to contribute another pull request so the fuzzers > will run on a daily basis via Fuzzit integration? Once we merge this, why not? Before merging this, I see little benefit in that, beside cluttering my inbox ;-) > This way it may find new bugs and also catch If bugs are introduced > again. How is Fuzzit different from oss-fuzz, since I have the long term plan of getting exiv2 into oss-fuzz. > > Cheers, > Yevgeny. > > On Thu, Jul 4, 2019, 10:36 AM D4N \*\*\*@\*\*\*.\*\*\*> wrote: > >> \*\*\*@\*\*\*.\*\*\*\* requested changes on this pull request. >> >> Wow, thanks for this contribution! >> >> However, by removing EXIV2\_TEAM\_USE\_SANITIZERS you effectively crippled >> our CI pipeline to no longer run with ASAN + UBSAN. Unless this is fixed, >> this PR is a nogo. Fixing this will probably require some refactoring of >> the CMake code, please tell if you want to undertake this (we can take care >> of that too). >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> < #943?email\_source=notifications&email\_token=AD52CDS4ZZZEBEFYE7JUSETP5WZBPA5CNFSM4H5EZH42YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB5PU2ZI#pullrequestreview-257903973 >, >> or mute the thread >> < https://github.com/notifications/unsubscribe-auth/AD52CDVPNEGL2WSEEC6Z5WDP5WZBPANCNFSM4H5EZH4Q > >> . >> > > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > #943 (comment) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#943?email\_source=notifications&email\_token=AD52CDRGV3NE734S4H6OGVTP5X6UTA5CNFSM4H5EZH42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZHPQZA#issuecomment-508491876>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD52CDVX5GNQ2WV5OB7E3VDP5X6UTANCNFSM4H5EZH4Q\> .

Gentlemen:

I see you've all been busy while Alison and I have been having fun in the Baltic. Is this change in 0.27-maintenance?

This is quite a major change to introduce into v0.27.2. Can I proceed to release v0.27.2 from PR #940?

@cryptomilk @kevinbackhouse @piponazo @D4N @yevgenypats Is everybody happy about this being delayed for v0.27.3 scheduled for 2019-09-30?

Copy link

Member

****D4N** commented Jul 11, 2019**

@clanmills This PR is not for 0.27-maintenance and will probably be dropped in favor of #945.

This morning, I did a $ git pull --rebase, and code relating to this arrived on my laptop:

    690 rmills@rmillsmbp:~/gnu/github/exiv2/0.27-maintenance $ git pull --rebase
    remote: Enumerating objects: 4241, done.
    remote: Counting objects: 100% (3174/3174), done.
    remote: Compressing objects: 100% (857/857), done.
    remote: Total 2422 (delta 1843), reused 2113 (delta 1540), pack-reused 0
    Receiving objects: 100% (2422/2422), 478.72 KiB | 446.00 KiB/s, done.
    Resolving deltas: 100% (1843/1843), completed with 286 local objects.
    From https://github.com/exiv2/exiv2
       1a9bae4f..b7a97854  0.27-maintenance -> origin/0.27-maintenance
       a803ce3b..1de8e734  master           -> origin/master
    Updating 1a9bae4f..b7a97854
    Fast-forward
     src/mrwimage.cpp                        |  22 +++++++++++++++-------
     test/data/issue_943_poc1.mrm            | Bin 0 -> 37 bytes
     test/data/issue_943_poc2.mrm            | Bin 0 -> 25 bytes
     tests/bugfixes/github/test_issue_943.py |  25 +++++++++++++++++++++++++
     4 files changed, 40 insertions(+), 7 deletions(-)
     create mode 100644 test/data/issue_943_poc1.mrm
     create mode 100644 test/data/issue_943_poc2.mrm
     create mode 100644 tests/bugfixes/github/test_issue_943.py
    691 rmills@rmillsmbp:~/gnu/github/exiv2/0.27-maintenance $ 
    

I think these mrm files are minolta stuff and that's 946 and 948. Confused!

@clanmills: What you're seeing there is #946, which I targeted at 0.27-maintenance. The other fix is #944, but I forgot to target that at 0.27-maintenance when I created the PR, so it is currently targeting master instead. Would it be possible to get both #946 and #944 into v0.27.2?

We can put it into v0.27.2. However I don't like code changes between the final RC and Release.

If you feel this (and other good stuff) should go into 0.27.2, then we can do 0.27.2.3 (Release Candidate 3) this weekend, and release v0.27.2 at the end of July.

Team Exiv2 doesn't have a constitution or voting procedure because we usually agree! I'm happy to do what the team things is best!

Copy link

Member

****D4N** commented Jul 18, 2019**

Closing this as #945 has been merged.

CVE-2019-13504: Add libFuzzer integration + report bug by yevgenypats · Pull Request #943 · Exiv2/exiv2

Mailvelope prior to 3.3.0 allows private key operations without user interaction via its client-API. By modifying an URL parameter in Mailvelope, an attacker is able to sign (and encrypt) arbitrary messages with Mailvelope, assuming the private key password is cached. A second vulnerability allows an attacker to decrypt an arbitrary message when the GnuPG backend is used in Mailvelope.

CVE-2019-9149: mailvelope/Changelog.md at master · mailvelope/mailvelope

DNN (aka DotNetNuke) 9.2 through 9.2.1 uses a weak encryption algorithm to protect input parameters.

CVE-2018-15811: Releases · dnnsoftware/Dnn.Platform

Incorect derivation of a packet length in WebRTC in Google Chrome prior to 68.0.3440.75 allowed a remote attacker to potentially exploit heap corruption via a crafted video file.

**Chrome Releases**

Release updates from the Chrome team

CVE-2018-6156: Stable Channel Update for Desktop

Use after free in V8 in Google Chrome prior to 74.0.3729.108 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

CVE-2019-5813

Object lifetime issue in V8 in Google Chrome prior to 74.0.3729.108 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

CVE-2019-5807

Object lifetime issue in Blink in Google Chrome prior to 72.0.3626.121 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page.

CVE-2019-5786

Inappropriate implementation in Blink in Google Chrome prior to 74.0.3729.108 allowed a remote attacker to bypass same origin policy via a crafted HTML page.

Tag

#google