From ${URL} : Description Two vulnerabilities have been discovered in Motion, which can be exploited by malicious people to conduct cross-site scripting and request forgery attacks. 1) Input passed via the "process_id_file" parameter to /0/config/set is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site. 2) The application allows users to perform certain actions via HTTP requests without performing proper validity checks to verify the requests. This can be exploited to e.g. manipulate certain configuration settings or conduct SQL injection attacks when a logged-in user visits a specially crafted web page. The vulnerabilities are confirmed in version 3.2.12. Other versions may also be affected. Solution: No official solution is currently available. Provided and/or discovered by: xistence Original Advisory: http://packetstormsecurity.com/files/122171/Motion-3.2.12-XSS-CSRF-Buffer-Overflow-SQL-Injection.html @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
Per the previous comments links the buffer overflow is still present: localhost libtirpc # motion -p /tmp/`python -c 'print "\x41"*5000'` *** buffer overflow detected ***: motion terminated ======= Backtrace: ========= /lib64/libc.so.6(+0x72443)[0x7fbabaec3443] /lib64/libc.so.6(__fortify_fail+0x37)[0x7fbabaf4abd7] /lib64/libc.so.6(+0xf7c70)[0x7fbabaf48c70] motion[0x407de2] motion[0x4088c3] motion[0x40511e] motion[0x4037ea] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7fbabae71630] motion[0x403e49] ======= Memory map: ======== 00400000-0042f000 r-xp 00000000 fd:02 292463 /usr/bin/motion 0062e000-0062f000 r--p 0002e000 fd:02 292463 /usr/bin/motion 0062f000-00632000 rw-p 0002f000 fd:02 292463 /usr/bin/motion 00632000-00679000 rw-p 00000000 00:00 0 [heap] 7fbabac3a000-7fbabac4f000 r-xp 00000000 fd:02 1076501 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 7fbabac4f000-7fbabae4f000 ---p 00015000 fd:02 1076501 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 7fbabae4f000-7fbabae50000 r--p 00015000 fd:02 1076501 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 7fbabae50000-7fbabae51000 rw-p 00016000 fd:02 1076501 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 7fbabae51000-7fbabafe4000 r-xp 00000000 fd:02 1092990 /lib64/libc-2.22.so 7fbabafe4000-7fbabb1e3000 ---p 00193000 fd:02 1092990 /lib64/libc-2.22.so 7fbabb1e3000-7fbabb1e7000 r--p 00192000 fd:02 1092990 /lib64/libc-2.22.so 7fbabb1e7000-7fbabb1e9000 rw-p 00196000 fd:02 1092990 /lib64/libc-2.22.so 7fbabb1e9000-7fbabb1ed000 rw-p 00000000 00:00 0 7fbabb1ed000-7fbabb244000 r-xp 00000000 fd:02 668092 /usr/lib64/libjpeg.so.62.1.0 7fbabb244000-7fbabb443000 ---p 00057000 fd:02 668092 /usr/lib64/libjpeg.so.62.1.0 7fbabb443000-7fbabb444000 r--p 00056000 fd:02 668092 /usr/lib64/libjpeg.so.62.1.0 7fbabb444000-7fbabb445000 rw-p 00057000 fd:02 668092 /usr/lib64/libjpeg.so.62.1.0 7fbabb445000-7fbabb45c000 r-xp 00000000 fd:02 1092993 /lib64/libpthread-2.22.so 7fbabb45c000-7fbabb65b000 ---p 00017000 fd:02 1092993 /lib64/libpthread-2.22.so 7fbabb65b000-7fbabb65c000 r--p 00016000 fd:02 1092993 /lib64/libpthread-2.22.so 7fbabb65c000-7fbabb65d000 rw-p 00017000 fd:02 1092993 /lib64/libpthread-2.22.so 7fbabb65d000-7fbabb661000 rw-p 00000000 00:00 0 7fbabb661000-7fbabb683000 r-xp 00000000 fd:02 1092106 /lib64/ld-2.22.so 7fbabb854000-7fbabb858000 rw-p 00000000 00:00 0 7fbabb880000-7fbabb882000 rw-p 00000000 00:00 0 7fbabb882000-7fbabb883000 r--p 00021000 fd:02 1092106 /lib64/ld-2.22.so 7fbabb883000-7fbabb884000 rw-p 00022000 fd:02 1092106 /lib64/ld-2.22.so 7fbabb884000-7fbabb885000 rw-p 00000000 00:00 0 7fff55cbc000-7fff55cde000 rw-p 00000000 00:00 0 [stack] 7fff55de6000-7fff55de9000 r--p 00000000 00:00 0 [vvar] 7fff55de9000-7fff55deb000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted @maintainer(s), no obvious patches from upstream and I did not test the XSS or XSRF vulnerabilities. Time for tree cleaning?
# Aaron Bauman <bman@gentoo.org> (26 Jun 2016) # Unpatched security vulnerability and dead upstream # per bug #475120. Removal in 30 days media-video/motion https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61de68f69fdf7dd0aaa53303517c0e59738034c3
(In reply to Aaron Bauman from comment #2) > # Aaron Bauman <bman@gentoo.org> (26 Jun 2016) > # Unpatched security vulnerability and dead upstream > # per bug #475120. Removal in 30 days > media-video/motion > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=61de68f69fdf7dd0aaa53303517c0e59738034c3 This vulnerability is no longer present on version 3.4.1rc01: http://www.lavrsen.dk/foswiki/pub/Motion/PatchworkForNewRelease/motion_3.4.1rc01.tar.gz
This is a useful utility I've been using for basic motion-detection on v4l devices (pre RTSP ethernet cameras). I see there is a fork being updated at https://github.com/Mr-Dave/motion - please can we review whether the issues referred to in this bug are applicable to this fork?
(In reply to William Breathitt Gray from comment #3) > > This vulnerability is no longer present on version 3.4.1rc01: > http://www.lavrsen.dk/foswiki/pub/Motion/PatchworkForNewRelease/motion_3.4. > 1rc01.tar.gz How on earth did you find that?! But kudos non-the-less! :]
(In reply to Michael Everitt (IRC: veremit) from comment #4) > This is a useful utility I've been using for basic motion-detection on v4l > devices (pre RTSP ethernet cameras). > > I see there is a fork being updated at https://github.com/Mr-Dave/motion - > please can we review whether the issues referred to in this bug are > applicable to this fork? of course. any testing you can do would help. I will review it as soon as I can as well.
(In reply to Michael Everitt (IRC: veremit) from comment #5) > (In reply to William Breathitt Gray from comment #3) > > > > This vulnerability is no longer present on version 3.4.1rc01: > > http://www.lavrsen.dk/foswiki/pub/Motion/PatchworkForNewRelease/motion_3.4. > > 1rc01.tar.gz > > How on earth did you find that?! But kudos non-the-less! :] There appears to be a current effort to merge Mr-Dave's Github fork into the official motion SVN repository: http://www.lavrsen.dk/foswiki/bin/view/Motion/PatchworkForNewRelease However, for this Gentoo package, it may be better to simply follow Mr-Dave's Github repository (https://github.com/Mr-Dave/motion.git), as it has become the de facto baseline with the latest development and responsive bug support; the official motion SVN repository has felt rather stagnant unfortunately over the past few years. :(
No longer masked for removal, but retaining security mask. New upstream fork available. No response from media-video project for new ebuild or patches.
Created attachment 441666 [details] motion-3.4.1 ebuild This ebuild is for motion version 3.4.1rc01 (part of the upstream attempt to merge Mr-Dave's Github fork). This motion version should resolve the security vulnerability reported in bug #475120.
Still no maintainer for this. Adding treecleaners.
Upstream has reported a new Github project: https://github.com/Motion-Project/motion
Release 3.4.1~rc01 (https://github.com/Motion-Project/motion/archive/release-3.4.1.tar.gz) on new Github project site appears to be the same as the prerelease I posted in an earlier comment on this bugzilla. I went ahead and tested the latest Release 4.0.1 (https://github.com/Motion-Project/motion/archive/release-4.0.1.tar.gz), and could not manifest the buffer overflow issue; it looks like the vulnerability is not present in this proper release either.
(In reply to William Breathitt Gray from comment #12) > [...] > I went ahead and tested the latest Release 4.0.1 > (https://github.com/Motion-Project/motion/archive/release-4.0.1.tar.gz), and > could not manifest the buffer overflow issue; it looks like the > vulnerability is not present in this proper release either. William, are you willing to proxy-maintain this package?
(In reply to Wolfram Schlich from comment #13) > (In reply to William Breathitt Gray from comment #12) > > [...] > > I went ahead and tested the latest Release 4.0.1 > > (https://github.com/Motion-Project/motion/archive/release-4.0.1.tar.gz), and > > could not manifest the buffer overflow issue; it looks like the > > vulnerability is not present in this proper release either. > > William, are you willing to proxy-maintain this package? Sure, I would be happy to proxy-maintain this package. I'm not currently a proxy maintainer for other packages on Gentoo, so I would just need some guidance on the process of becoming a proxy maintainer for this package.
(In reply to William Breathitt Gray from comment #14) > (In reply to Wolfram Schlich from comment #13) > > [...] > > William, are you willing to proxy-maintain this package? > > Sure, I would be happy to proxy-maintain this package. I'm not currently a > proxy maintainer for other packages on Gentoo, so I would just need some > guidance on the process of becoming a proxy maintainer for this package. Great! Please check: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Policies_and_Guidelines I'll create a Maintainer bug as well as a Maintainership Request bug for you. Your nickname is 'vilhelmgray', right? If not, please tell me :-)
(In reply to Wolfram Schlich from comment #15) > [...] > I'll create a Maintainer bug as well as a Maintainership Request bug for you. I created the Maintainer bug: #604142 It seems you have to create the Maintainership Request bug yourself, though: Product: Gentoo Linux Component: Current packages Summary: "Maintainership request: media-video/motion" Description: Something like "I would like to proxy-maintain this package." ;)
Created attachment 458790 [details] motion-4.0.1 ebuild Here's an ebuild for the 4.0.1 release hosted on Github at https://github.com/Motion-Project/motion/archive/release-4.0.1.tar.gz
William, the 4.0.1 ebuild is compiling, but not working very well. Most notably the init script is not gentooish: newinitd "${D}"/usr/share/doc/${PF}/examples/motion.init-Debian motion I'm no proxy maintainer, but I'm dealing with a few tailored ebuilds in my overlay. Are you still working on this or shall I have a look as well? Just want to avoid doing things twice.
(In reply to Sven Schwyn (svoop) from comment #18) > William, the 4.0.1 ebuild is compiling, but not working very well. Most > notably the init script is not gentooish: > > newinitd "${D}"/usr/share/doc/${PF}/examples/motion.init-Debian motion > > I'm no proxy maintainer, but I'm dealing with a few tailored ebuilds in my > overlay. Are you still working on this or shall I have a look as well? Just > want to avoid doing things twice. I definitely welcome any help so feel free to check it out; the more eyes, the better in my opinion. This was an area of the ebuild that I did have trouble since I'm not certain of the best approach to handle the file installations (I bet the subsequent mv line could also be made less ugly). What would you suggest?
I've worked on the motion-4.0.1.ebuild for a while now, based upon the ebuild from William. I've committed that with appropriate credits to William. Please check it out: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=296feb41fc063071d4df2dee73fb6e9831d71ee9 Feedback welcome! We should now also try to get the proxy maintainer status done for William. Also, motion-3* should be removed from portage ASAP, I guess.
@William: Not sure whether it's still state of the art, but you could replace the "mv" with something similar to this (untested, the path after "doins" is most likely not correct): insinto /etc/motion doins etc/${PN}/${PN}{-dist,}.conf || die "installing config files failed"
@Wolfram: The init script works pretty well, the only issue I see after a quick try is the "daemon off" line in the default "/etc/motion/motion.conf" file installed by the ebuild. It causes the init script to hang forever. Patching this to "daemon on" prior to installing it will do the trick.
(In reply to Sven Schwyn (svoop) from comment #21) > @William: Not sure whether it's still state of the art, but you could > replace the "mv" with something similar to this (untested, the path after > "doins" is most likely not correct): > > insinto /etc/motion > doins etc/${PN}/${PN}{-dist,}.conf || die "installing config files failed" I chose to not create a /etc/motion/motion.conf at all now but to keep it as motion-dist.conf together with a notice for the user. (In reply to Sven Schwyn (svoop) from comment #22) > @Wolfram: The init script works pretty well, the only issue I see after a > quick try is the "daemon off" line in the default "/etc/motion/motion.conf" > file installed by the ebuild. It causes the init script to hang forever. > Patching this to "daemon on" prior to installing it will do the trick. Ah, that's because I forgot to update the reference to the init script from motion.initd-r2 to motion.initd-r3, sorry :( Fixed! I'll commit the fixed motion-4.0.1-r1.ebuild later today, as I have to run now. Thank you, Sven!
(In reply to Wolfram Schlich from comment #23) > [...] > I'll commit the fixed motion-4.0.1-r1.ebuild later today, as I have to run > now. Done now: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4a61c24fdb0a4642b8dbc90292a7c4b128bbf28 @Sven,William: Can you guys please re-check? @William: Have you created the maintainership request bug already? If not, please do so. @Security: How should we proceed to get =motion-3* removed from the tree now (as well as the corresponding package.mask entry)?
(In reply to Wolfram Schlich from comment #24) > (In reply to Wolfram Schlich from comment #23) > > [...] > > @Security: How should we proceed to get =motion-3* removed from the tree now > (as well as the corresponding package.mask entry)? As the maintainer(s) you can request stabilization here in this bug. Following that you can remove the masked ebuilds and we can close. The 30 day period is waived due to the security status. Would you like to stable, now? Dependency removed as it should not block a security bug.
(In reply to Wolfram Schlich from comment #24) > (In reply to Wolfram Schlich from comment #23) > > [...] > > I'll commit the fixed motion-4.0.1-r1.ebuild later today, as I have to run > > now. > > Done now: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=d4a61c24fdb0a4642b8dbc90292a7c4b128bbf28 > > @Sven,William: > Can you guys please re-check? > > @William: Have you created the maintainership request bug already? If not, > please do so. > > @Security: How should we proceed to get =motion-3* removed from the tree now > (as well as the corresponding package.mask entry)? Hi Wolfram Schlich, I noticed "sourceforge" is still listed as the upstream remote-id type in the motion metadata.xml file. Should this be removed now that upstream releases via GitHub? I also created a maintainership request bug (https://bugs.gentoo.org/show_bug.cgi?id=604264); I think the next step is for a Developer to CC themselves so the status can be changed to CONFIRMED.
(In reply to William Breathitt Gray from comment #26) > [...] > Hi Wolfram Schlich, > > I noticed "sourceforge" is still listed as the upstream remote-id type in > the motion metadata.xml file. Should this be removed now that upstream > releases via GitHub? Yes, thank you. Fixed: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=edca66bf519659ae62fe1cbd79bab3102aa27991 > I also created a maintainership request bug > (https://bugs.gentoo.org/show_bug.cgi?id=604264); I think the next step is > for a Developer to CC themselves so the status can be changed to CONFIRMED. Great! I added you as a proxied maintainer now (see commit above). (In reply to Aaron Bauman from comment #25) > (In reply to Wolfram Schlich from comment #24) > > (In reply to Wolfram Schlich from comment #23) > > > [...] > > > > @Security: How should we proceed to get =motion-3* removed from the tree now > > (as well as the corresponding package.mask entry)? > > As the maintainer(s) you can request stabilization here in this bug. > Following that you can remove the masked ebuilds and we can close. The 30 > day period is waived due to the security status. > > Would you like to stable, now? Well, I'd like to get feedback regarding the fixed init script from Sven Schwyn (svoop) <svoop@delirium.ch> first, if it would be ok you to wait a bit longer...?
> Well, I'd like to get feedback regarding the fixed init script from Sven > Schwyn (svoop) <svoop@delirium.ch> first, if it would be ok you to wait a > bit longer...? The wait time is up to you as maintainer. Just giving you the options that are available. Let us know when you are ready :)
(In reply to Aaron Bauman from comment #28) > > Well, I'd like to get feedback regarding the fixed init script from Sven > > Schwyn (svoop) <svoop@delirium.ch> first, if it would be ok you to wait a > > bit longer...? > > The wait time is up to you as maintainer. Just giving you the options that > are available. Let us know when you are ready :) As I got not feedback regarding motion-4.0.1-r1 for over a week now, I'd like to have it stabled now. Can you please take care? Thank you! :)
(In reply to Wolfram Schlich from comment #29) > > The wait time is up to you as maintainer. Just giving you the options that > > are available. Let us know when you are ready :) > > As I got not feedback regarding motion-4.0.1-r1 for over a week now, I'd > like to have it stabled now. Can you please take care? Thank you! :) Is there any reason you as maintainer can't initiate stabilization?
I adjusted the PMASK: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=850e6cdf235a45d4c3cc0f26ce7187616768f13e @ Arches, please test and mark stable: =media-video/motion-4.0.1-r1
@ Maintainer(s): Had to p.use.mask "mmal" because media-libs/raspberrypi-userland is not keyworded.
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
(In reply to Thomas Deutschmann from comment #32) > @ Maintainer(s): Had to p.use.mask "mmal" because > media-libs/raspberrypi-userland is not keyworded. Looks like media-libs/raspberrypi-userland is only available on ~arm. Perhaps we should add a ~arm dependency for the mmal option in the motion ebuild.
(In reply to Thomas Deutschmann from comment #32) > @ Maintainer(s): Had to p.use.mask "mmal" because > media-libs/raspberrypi-userland is not keyworded. Oh, we missed that one, sorry :( Thank you! (In reply to William Breathitt Gray from comment #35) > (In reply to Thomas Deutschmann from comment #32) > > @ Maintainer(s): Had to p.use.mask "mmal" because > > media-libs/raspberrypi-userland is not keyworded. > > Looks like media-libs/raspberrypi-userland is only available on ~arm. > Perhaps we should add a ~arm dependency for the mmal option in the motion > ebuild. Here's what Thomas did: --8<-- profiles/arch/arm/package.use.mask:media-video/ffmpeg -mmal profiles/base/package.use.mask:media-video/motion mmal --8<-- I think that's exactly what's needed, no? Cheers, Wolfram
(In reply to Wolfram Schlich from comment #36) > (In reply to Thomas Deutschmann from comment #32) > > @ Maintainer(s): Had to p.use.mask "mmal" because > > media-libs/raspberrypi-userland is not keyworded. > > Oh, we missed that one, sorry :( > Thank you! > > (In reply to William Breathitt Gray from comment #35) > > (In reply to Thomas Deutschmann from comment #32) > > > @ Maintainer(s): Had to p.use.mask "mmal" because > > > media-libs/raspberrypi-userland is not keyworded. > > > > Looks like media-libs/raspberrypi-userland is only available on ~arm. > > Perhaps we should add a ~arm dependency for the mmal option in the motion > > ebuild. > > Here's what Thomas did: > --8<-- > profiles/arch/arm/package.use.mask:media-video/ffmpeg -mmal > profiles/base/package.use.mask:media-video/motion mmal > --8<-- > I think that's exactly what's needed, no? > > Cheers, > Wolfram Yes that should be correct since media-video/ffmpeg is the only other package with the mmal option if I'm not mistaken.
The mmal option enables support for Multi-Media Abstraction Layer which is an interface to multimedia components running on VideoCore. Since VideoCore is a multimedia processor architecture only available on ARM, would it make sense to mask the mmal USE flag in the use.mask file rather than package.use.mask file.
(In reply to William Breathitt Gray from comment #38) > The mmal option enables support for Multi-Media Abstraction Layer which is > an interface to multimedia components running on VideoCore. Since VideoCore > is a multimedia processor architecture only available on ARM, would it make > sense to mask the mmal USE flag in the use.mask file rather than > package.use.mask file. Ah, I understand. You suggest adding "mmal" to profiles/base/use.mask and "-mmal" to profiles/arch/arm/use.mask while removing all of the existing entries related to mmal (also for ffmpeg) in profiles/base/package.use.mask and profiles/arch/arm/package.use.mask, right?
(In reply to Wolfram Schlich from comment #39) > (In reply to William Breathitt Gray from comment #38) > > The mmal option enables support for Multi-Media Abstraction Layer which is > > an interface to multimedia components running on VideoCore. Since VideoCore > > is a multimedia processor architecture only available on ARM, would it make > > sense to mask the mmal USE flag in the use.mask file rather than > > package.use.mask file. > > Ah, I understand. > > You suggest adding "mmal" to profiles/base/use.mask and "-mmal" to > profiles/arch/arm/use.mask while removing all of the existing entries > related to mmal (also for ffmpeg) in profiles/base/package.use.mask and > profiles/arch/arm/package.use.mask, right? Yes, exactly. Since mmal is well defined as an ARM specific feature, and only used by the ffmpeg and motion packages, it would probably be best to mask it to be available only for arm.
GLSA Vote: No @ Maintainer(s): Please cleanup and drop <media-video/motion-4.0.1-r1!
(In reply to Thomas Deutschmann from comment #41) > GLSA Vote: No > > @ Maintainer(s): Please cleanup and drop <media-video/motion-4.0.1-r1! Done.
All done, repository is clean.
