CVE-2014-3634: remote syslog PRI vulnerability

a guest Sep 30th, 2014 3,291 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. remote syslog PRI vulnerability
  2. ===============================
  4. CVE: CVE-2014-3634
  6. Status of this report
  7. ---------------------
  8. FINAL
  10. Embargo Date
  11. ------------
  12. Please keep this information private until after
  14.    2014-09-30, 12:00 CEDT
  17. Reporter
  18. -------
  19. Rainer Gerhards <>, rsyslog project lead
  21. Affected
  22. --------
  23. - rsyslog, most probably all versions (checked 5.8.6+)
  24. - sysklogd (checked most recent versions)
  25. - potentially others (see root cause)
  28. Root Cause
  29. ----------
  30. Note: rsyslogd was forked from sysklogd, and the root cause applies to
  31. both. For simplicity, here I use sysklogd as this is the base code.
  33. The system header file /usr/include/*/syslog.h contains the following definitions
  35.    #define      LOG_NFACILITIES 24      /* current number of facilities */
  36.    #define      LOG_FACMASK     0x03f8  /* mask to extract facility part */
  37.                                 /* facility of pri */
  38.    #define      LOG_FAC(p)      (((p) & LOG_FACMASK) >> 3)
  40. [This is from Ubuntu 12.04LTS, but can be found similarly in most, if
  41. not all, distributions].
  43. The define LOG_NFACILITIES is used by sysklogd to size arrays for facility
  44. processing. In sysklogd, an array for selector matching is using this. Rsyslog
  45. has additional array. The macro LOG_FAC() is used to extract the facility from
  46. a syslog PRI [RFC3164, RFC 5424]. Its result is used to address the arrays.
  47. Unfortunately, the LOG_FACMASK permits PRI values up to 0x3f8 (1016 dec). This
  48. translates to 128 facilities. Consequently, for PRI values above 191 the
  49. LOG_NFACILITIES arrays are overrun.
  51. Other applications may have similar problems, as LOG_NFACILITES "sounds" like
  52. the max value that LOG_FAC() can return. It would probably make sense to
  53. check why there is a difference between LOG_NFACILITES and LOG_FACMASK, and
  54. if this really needs to stay. A proper fix would probably be to make LOG_FAC
  55. return a valid (maybe special) facility if an invalid one is provided. This
  56. is the route taken in rsyslog patches.
  59. Effect in Practice
  60. ------------------
  62. General
  63. ~~~~~~~
  64. Almost all distributions do ship rsyslog without remote reception by
  65. default and almost all distros also put firewall rules into place that
  66. prevent reception of syslog messages from remote hosts (even if rsyslog
  67. would be listening). With these defaults, it is impossible to trigger
  68. the vulnerability in v7 and v8. Older versions may still be vulnerable
  69. if a malicious user writes to the local log socket.
  71. Even when configured to receive remote message (on a central server),
  72. it is good practice to protect such syslog servers to accept only
  73. messages from trusted peers, e.g. within the relay chain. If setup in
  74. such a way, a trusted peer must be compromised to send malfromed
  75. messages. This further limits the magnitude of the vulnerability.
  77. If, however, any system is permitted to send data unconditionally to
  78. the syslogd, a remote attack is possible.
  80. sysklogd
  81. ~~~~~~~~
  82. Sysklogd is mildly affected. Having a quick look at the current git master
  83. branch, the wrong action may be applied to messages with invalid facility.
  85. A segfault seems unlikely, as the maximum misadressing is 104 bytes of the
  86. f_pmask table, which is always within properly allocated memory (albeit to
  87. wrong data items). This can lead to triggering invalid selector lines and
  88. thus wrongly writing to files or wrongly forwarding to other hosts.
  90. rsyslogd
  91. ~~~~~~~~
  92. Rsyslogd experiences the same problem as sysklogd.
  94. However, more severe effects can occur, BUT NOT WITH THE DEFAULT CONFIGURATION.
  95. The most likely and thus important attack is a remote DoS. Some
  96. of the additional tables are writable and can cause considerable misadressing.
  97. This is especially true for versions 7 and 8. In those versions, remote code
  98. injection may also be possible by a carefully crafted package. It sounds hard
  99. to do, but it cannot be totally outruled [we did not check this in depth].
  101. A segfault (and thus Dos) has the following preconditions:
  102. - the rsyslog property "pri-text" must be used, either in
  103.   * templates
  104.   * conditional statements (RainerScript and property-based filters)
  105. - the property must actually be accessed
  106.   With traditional selector lines, this depends on the facility causing
  107.   a misadressing that leads to reading a 1 from the misaccessed location.
  109. When the preconditions are met, misadressing happens. The code uses a string
  110. table and a table of string lengths. Depending on memory layout at time of
  111. misadressing and depending on the actual invalid PRI value, the lookup to
  112. the string table can lead to a much to long length, which is the used in
  113. buffer copy calculations. High PRI values close to the max of 1016 potentially
  114. cause most problems, but we have also seen segfaults with very low invalid
  115. PRI values.
  117. Note that, as usual in such situations, a segfault may not happen immediately.
  118. Instad some data structures may be damaged (e.g. from the memory allocator)
  119. which will later on result in a segfault.
  121. In v5 and below, a segfault is very unlikely, as snprintf() is used to generate
  122. the pri-text property. As such, no write overrun can happen (but still garbagge
  123. be contained inside the property). A segfault could theoretically happen if the
  124. name lookup table indices cause out-of-process misadressing. We could not manage
  125. to produce a segfault with v5.
  127. Versions 7.6.3 and 7.6.4 already have partial fixes for the issue and will not
  128. be vulnerable to a segfault (but the mild other issues described).
  130. All other versions 7 and 8 are vulnerable. Version 6 was not checked as it seems
  131. no longer be used in practice (it was an interim version). No patch for version 6
  132. will be provided.
  134. Note that a segfault of rsyslog can cause message loss. There are multiple
  135. scenarios for this, but likely ones are:
  137. - reception via UDP, where all messages arriving during downtime are lost
  138. - corruption of disk queue structures, which can lead to loss of all disk
  139.   queue contents (manual recovery is possible).
  141. This list does not try to be complete. Note that disk queue corruption is likely
  142. to occur in default settings, because the important queue information file (.qi)
  143. is only written on successful shutdown. Without a valid .qi file, queue message
  144. files cannot be processed.
  147. How to Exploit
  148. --------------
  149. A syslog message with an invalid PRI value needs to be sent. It is sufficient
  150. to send just the PRI as in this example
  152. "<201>"
  154. Any message starting with "<PRI>" where PRI is an integer greater than 191
  155. can trigger the problem. The maximum offset that can be generated is with
  156. PRI equal to 1016, as this is the modulus used due to LOG_FACMASK.
  158. Note that messages with
  159. - PRI > 191  and
  160. - PRI modulus 1016 <= 191
  161. will not lead to misadressing but go into the wrong bin.
  163. Messsages with
  164. - PRI > 191
  165. - PRI modulus 1016 > 191
  166. will go into the wrong bin and lead to misadressing.
  169. Severity
  170. --------
  171. Given the triggering scenarios, the fact that multiple changes must be made to
  172. default system configurations and potential problems we classify the severity
  173. of this vulnerability as
  175. MEDIUM
  177. Note that the probability of a successful attack is LOW. However, the risk of
  178. message loss is HIGH in those rare instances where an attack is successful. As
  179. mentioned above, it cannot totally be outruled that remote code injection is
  180. possible using this vulnerability.
  182. This vulnerability is at least not publicly know. Based on (no) bug reports, it
  183. seems unlikely that it is being exploited, but that's obviously hard to know for
  184. sure.
  187. Patches
  188. -------
  189. Patches are available for versions known to be in wide-spread use.
  191. Version 8.4.1 is not vulnerable. Version 7.4.6, while no longer being project
  192. supported received a patch and is also not vulnerable.
  194. All patches and downloads can be found on
RAW Paste Data