A CVE has been assigned for a security issue fixed upstream in xdelta3: http://openwall.com/lists/oss-security/2016/02/08/2 Mageia 5 is also affected. The issue is fixed in 3.0.9 or 3.1.0, and the upstream commit to fix it is linked in the message above, but it doesn't apply cleanly (or even close) to the 3.0.0 version that we have, so it appears that this unmaintained package needs to be updated. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA5TOO
Debian-LTS has issued an advisory for this today (February 16): http://lwn.net/Alerts/675811/
URL: (none) => http://lwn.net/Vulnerabilities/675832/
Assigning this security bug to packagers collectively since graphicsmagick has no registered maintainer. To packagers: it would be nice to have a maintainer for this package so that David Walser knows who to assign security bugs for it to in the future.
Assignee: bugsquad => pkg-bugs
Debian's patch for 3.0.0 only changes 2 lines, so apparently all of the upstream patch wasn't needed. Patched packages uploaded for Mageia 5 and Cauldron. Advisory: ======================== Updated xdelta3 package fixes security vulnerability: Stepan Golosunov discovered that xdelta3, a diff utility which works with binary files, is affected by a buffer overflow vulnerability within the main_get_appheader function, which may lead to the execution of arbitrary code (CVE-2014-9765). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9765 https://www.debian.org/security/2016/dsa-3484 ======================== Updated packages in core/updates_testing: ======================== xdelta3-3.0.0-5.1.mga5 from xdelta3-3.0.0-5.1.mga5.src.rpm
Whiteboard: MGA5TOO => (none)Version: Cauldron => 5Assignee: pkg-bugs => qa-bugs
mga5 x86_64 Mate Installed the release version of xdelta3. $ sudo urpmi xdelta3 Package xdelta3-3.0.0-5.mga5.x86_64 is already installed Compiled a couple of simple programs to produce binaries for comparison using xdelta3. delta1.c: #include <stdio.h> #include <string.h> #include <stdlib.h> // Hello World program for testing xdelta3 int main( ) { char *a; a = (char *)malloc( 32 ); strcpy( a, "Good morning QA\n" ); puts( a ); return( 0 ); } delta2.c: #include <stdio.h> int main( ) { puts( "Good morning Bug Busters\n" ); return( 0 ); } $ gcc -o delta1 delta1.c $ gcc -o delta2 delta2.c Run the two exe files; ./delta1 and ./delta2 Generate a difference (patch) file for the two binaries: $ xdelta3 -e -s delta1 delta2 delta Apply the patch to delta1 to generate a new file identical to delta2. $ xdelta3 -d -s delta1 delta delta12 $ chmod +x delta12 $ ./delta12 Installed the update package xdelta3-3.0.0-5.1.mga5.x86_64. Procedure continued: Recreate the binary for the first program $ gcc -o delta1 delta1.c Generate the patch file $ xdelta3 -f -s delta1 delta2 delta Apply the patch to delta1 $ xdelta3 -d -f -s delta1 delta delta12 $ chmod +x delta12 $ ./delta12 Note the use of -f to overwrite earlier files. This demonstrates that the package continues to work after the update.
CC: (none) => tarazed25
Whiteboard: (none) => has_procedure MGA5-64-OK
Ahem. Might have to reconsider that OK. Ran the builtin tests after the update and hit a failure involving appheader, which might be significant given that the overflow vulnerability is in main_get_appheader. $ xdelta3 test Xdelta version 3.0.0, Copyright (C) 2007, 2008, 2009, 2010, Joshua MacDonaldnXdelta comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; see "COPYING" for details. EXTERNAL_COMPRESSION=1 GENERIC_ENCODE_TABLES=0 GENERIC_ENCODE_TABLES_COMPUTE=0 REGRESSION_TEST=1 SECONDARY_DJW=1 SECONDARY_FGK=1 UNALIGNED_OK=1 VCDIFF_TOOLS=1 XD3_ALLOCSIZE=16384 XD3_DEBUG=0 XD3_ENCODER=1 XD3_POSIX=1 XD3_STDIO=0 XD3_WIN32=0 XD3_USE_LARGEFILE64=1 XD3_DEFAULT_LEVEL=3 XD3_DEFAULT_IOPT_SIZE=32768 XD3_DEFAULT_SPREVSZ=262144 XD3_DEFAULT_SRCWINSZ=67108864 XD3_DEFAULT_WINSIZE=8388608 XD3_HARDMAXWINSIZE=16777216 sizeof(void*)=8 sizeof(int)=4 sizeof(uint32_t)=4 sizeof(uint64_t)=8 sizeof(usize_t)=4 sizeof(xoff_t)=8 xdelta3: testing random_numbers... success xdelta3: testing decode_integer_end_of_input... success xdelta3: testing decode_integer_overflow... success xdelta3: testing encode_decode_uint32_t..................................... success xdelta3: testing encode_decode_uint64_t................................................................... success xdelta3: testing usize_t_overflow... success xdelta3: testing forward_match... success xdelta3: testing address_cache... success xdelta3: testing string_matching... success xdelta3: testing choose_instruction... success xdelta3: testing identical_behavior... success xdelta3: testing in_memory... success xdelta3: testing iopt_flush_instructions... success xdelta3: testing source_cksum_offset... success xdelta3: testing decompress_single_bit_error.... success xdelta3: testing decompress_single_bit_error (XD3_ADLER32).... success xdelta3: testing decompress_single_bit_error (XD3_SEC_FGK).... success xdelta3: testing decompress_single_bit_error (XD3_SEC_DJW).... success xdelta3: testing force_behavior... success xdelta3: testing stdout_behavior... success xdelta3: testing no_output... success xdelta3: testing appheader...cp: cannot stat âxdelta3â: No such file or directory failed: : XD3_INTERNAL 'xdelta3 test' on another machine which has not been updated runs through the full gamut of tests and exits cleanly. Wondering if this might be a path definition error in the update I did a 'touch xdelta3' in my test directory and ran the test again. It failed in a different way: xdelta3: testing appheader... failed: compare files: different length: XD3_INTERNAL Meanwhile over to my 32bit virtualbox.
In the preupdate test th no_output lines is followed by a different message: xdelta3: testing no_output... success xdelta3: testing command_line_arguments................ success which might indicate that the appheader section has been inserted, maybe to test the modified code.
mga5 i586 in virtualbox Mate Before updating, the 'xdelta3 test' ran to completion without errors. The enquiry commands returned sensible output. The simple test outlined in comment 4 returned the same results before and after the update but 'xdelta3 test' failed afterwards in the same way as on the 64bit system. strace does not provide any useful information as far as I can see. $ xdelta3 config provides information about the configuration $ xdelta3 printdelta delta gives details about the patch file. I would say that this is working for 32bit architectures as well and bearing in mind that the Debian Security Advisory claims that the original issue is fixed I am inclined to think that the 'test' fault is a fault in the test. It should be reported in any case. Will do that in due course. Leaving validation until later in case of objections.
Created attachment 7496 [details] Contains two slightly different C scripts
Adding feedback marker. David, could you check please.
Whiteboard: has_procedure MGA5-64-OK => has_procedure feedback MGA5-64-OK
Check what? We used Debian's patch which includes the fix and the test that Len mentioned. The failure code he got doesn't make sense, as it appears that one was removed by the patch.
Created attachment 7500 [details] strace output from xdelta3 test command This was obtained after the update was installed. $ strace xdelta3 test >& trace2
See attached strace output for the test command. Look for 'testing appheader' and then 'wait4(22060' which seems to indicate failure to find a file or link to 'xdelta3'. I am just guessing in saying that there might be a code error or something overlooked in the formulation of the test, unlikely I know.
Repeated these tests on a 32bit laptop. The simple procedure worked fine as for 64bit but 'xdelta3 test' came up with a different error message at the same point. xdelta3: testing stdout_behavior... success xdelta3: testing no_output... success xdelta3: testing appheader.../tmp/xdtest.recon2.4: line 1: delta1.c:: command not found /tmp/xdtest.recon2.4: line 5: //: Is a directory /tmp/xdtest.recon2.4: line 6: syntax error near unexpected token `(' /tmp/xdtest.recon2.4: line 6: `int main( )' failed: command exited non-zero: Unknown error 512 This does not make sense either. The symbolic link in /tmp appears to have been defined on my local test file delta1.c. ??? The test is not parsing this as C. So it has picked the wrong file. The error is not directly related to the bugfix but to the unit test for the bugfix, I would say. How this relates to the patch I have no idea but it does seem to be a separate issue and a minor new bug. I think we should let this go and I should open a new bug.
Labouring the point somewhat: What emerges from my experiments with the test option boils down to a missing file called xdelta3. I think that the test sets up a symbolic link to this file in /tmp and at some stage tries to access it. It so happens that my test directory contains an xdelta3 file with the code for the two hello world C scripts and this is what the application finds. [lcl@rutilicus ~/qa]$ locate xdelta3 /home/lcl/qa/xdelta3 /usr/bin/xdelta3 /usr/share/doc/xdelta3 /usr/share/doc/xdelta3/COPYING /usr/share/man/man1/xdelta3.1.xz $ mv xdelta3 hellow $ xdelta3 test ............ xdelta3: testing no_output... success xdelta3: testing appheader...cp: cannot stat âxdelta3â: No such file or directory failed: : XD3_INTERNAL Four possibilities at least: 1) Test file xdelta3 is missing from the package 2) xdelta3 is created on the fly but the symbolic link is not defined correctly 3) xdelta3 is created on the fly but is not where the program expects it to be 4) xdelta3 is the wrong name This is all shooting in the dark without having the appheader code to hand.
Whiteboard: has_procedure feedback MGA5-64-OK => has_procedure feedback MGA5-64-OK MGA5-32-OK
Yeah I guess the test is broken. It'd be nice if we had a maintainer to update this package.
Whiteboard: has_procedure feedback MGA5-64-OK MGA5-32-OK => has_procedure MGA5-64-OK MGA5-32-OK
@David, you said that the patch does not apply cleanly to our version but can we go with the upstream assertion that the issue is fixed and validate this? The package works as far as we have tested it. If we let it go I shall file a bug report against the appheader test and hope that somebody takes up the baton.
I think you can validate this.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Advisory uploaded. Great work on this Len.
Whiteboard: has_procedure MGA5-64-OK MGA5-32-OK => has_procedure advisory MGA5-64-OK MGA5-32-OK
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0084.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Before placing an order on the company's site, it is a good idea to read advancedwriters reviews. This review <a href="https://fallguys2.co/lolbeansio">lolbeans</a> provided a wealth of information on how to use the service.
CC: (none) => marianruliarulia
You can view in detail, the solutions to fix this issue at this link below: https://vulners.com/mageia/MGASA-2016-0084 https://nytsudoku.co/
CC: (none) => zlouis321