Opened 13 years ago

Closed 13 years ago

#4460 closed defect (fixed)

DoS on mythbackend port listeners

Reported by: jp@… Owned by: Isaac Richards
Priority: minor Milestone: 0.21
Component: mythtv Version: 0.20-fixes
Severity: medium Keywords:
Cc: Ticket locked: no


I recently encountered a way to reproducibly kill the mythbackend ![1!] listeners on ports 654![349!]. More details at:

Aside from pulling my hair out for an entire weekend, this obviously represents at least a potential LAN DoS.

Steps to reproduce (given for a Mythbuntu 7.10 ![1!] system, but trivially adaptable):

 # aptitude install monit
 # vi /etc/default/monit
    Change to "startup=1"
 # vi /etc/monit/monitrc
    Tweak settings as needed, I'm not 100% sure which one did it, none should be *able* to:
  ----- cut here ----
  check host mythtv-be-01 with address
   if failed port 2442 type tcp then alert # mtd (Myth DVD)
   if failed port 6543 type tcp then alert # mythbackend server
   if failed port 6544 type tcp then alert # mythbackend status
   if failed port 6549 type udp then alert # mythbackend
  ----- cut here ----
 # monit -T /etc/monit/monitrc
 # vi /etc/monit/monitrc
    Fix any errors the -T syntax checker found
 # monit -T /etc/monit/monitrc
 # /etc/init.d/monit start

That's it. Now every time Monit polls, your mythbackend will stop listening on its TCP/UDP ports.


[1] $ mythbackend --version
 Library API version     : 0.20.20070821-1
 Source code version     : 14283
 SVN Branch              : branches/release-0-20-fixes
 Options compiled in     :
 linux profile using_xvmcw using_v4l using_oss using_alsa using_arts using_jack using_ivtv using_firewire using_dbox2 using_hdhr using_ip_rec using_freebox using_live using_lirc using_joystick_menu using_dvb using_x11 using_xv using_xrandr using_xvmc using_xvmc_vld using_opengl_vsync using_opengl using_frontend using_backend using_bindings_perl

Change History (2)

comment:1 Changed 13 years ago by David.Whyte@…

This looks like a duplicate of Ticket #4174 which has since been (hopefully) resolved and closed.

comment:2 Changed 13 years ago by stuartm

Milestone: unknown0.21
Resolution: fixed
Status: newclosed

Torture tests performed on trunk by Michael Dean and James Meyer on the backend suggest this issue has been fixed, neither were able to trigger any bugs.

As we can't identify a single commit which fixes this problem and with 0.21 just weeks away this won't get backported to 0.20.

Note: See TracTickets for help on using tickets.