Security
Monkeysign 2.0
Monkeysign is one of several free-software projects hoping to increase the adoption of email encryption by making OpenPGP easier to use. Granted, OpenPGP ease-of-use is a rather large target to shoot at, but Monkeysign makes its task more manageable by focusing on just one portion of the problem: key signing. The project recently released a major update that users may find well worth exploring—particularly those who have found using OpenPGP to be a trying prospect in the past.
Monkeysign's 2.0 release was announced on October 20, followed by two minor updates: another on October 20 that implemented a few quick documentation and test fixes, and one on December 1 that closed some open bugs found by users. Developer Antoine Beaupré said in the 2.0 release announcement that the intent was to push the update out in time for its inclusion in Debian jessie, which was about to be frozen. Debian packages are provided on the project's download page, although most users will not find them necessary: Monkeysign is written in Python and installation by hand is a snap. The only noteworthy dependencies are the Python packages for GTK+ 2 and the QR-code packages qrencode and zbar. Monkeysign is, interestingly, an independent side-project of the Monkeysphere project team, who are seeking to replace the centralized certificate-authority system with a PGP-like web of trust.
Monkey see, monkey verify
The key ideas behind Monkeysign are the use of QR codes (rather than the usual hexadecimal strings) for key fingerprints and the automatic use of email to send key signatures to the owner of the key being signed. Monkeysign provides a graphical interface that lets users capture images from an attached webcam. The user aims the camera at a QR-encoded fingerprint, and the application grabs a still image of the QR code. Monkeysign then decodes the QR code and, if it is a valid 40-character key fingerprint, attempts to look up the key in the user's keyring, followed by fetching it from public keyservers. With the key retrieved, the user can then decide whether or not to proceed with signing it (using whatever means of verifying the owner's identity is required). If the user does sign the key, that signature is sent in an email to the address tied to the key (and, in fact, to each address individually, if there are several).
The QR-code features are limited to the GUI version of Monkeysign, which is launched with the command monkeyscan. The monkeysign command itself is the command-line version of the tool. It takes a key fingerprint as its argument, fetches and signs the key, then emails the resulting signature to its owner.
Using QR codes instead of hex fingerprints has at least two benefits, according to Monkeysign's documentation. First, QR codes can be scanned in through a webcam, thus reducing the chance of the user mistyping the fingerprint. Second, scanning the QR code is far faster than typing in the key fingerprint by hand, which reduces the hassle needed to sign a friend's key when its fingerprint is delivered, for example, on a business card. At key-signing parties, the cumulative time savings could be considerable.
Along those lines, Monkeysign's GUI is seemingly designed to optimize usage at keysigning events: it displays the user's own key-fingerprint QR code in the user interface next to the camera window, so that two Monkeysign-users can exchange codes almost instantaneously. The usual caveats about verifying the other party's identity apply, but Monkeysign generates the QR code that it displays based on the user's main public key (although an alternate key can be specified with the --user=foo command-line switch.
The Monkeysign GUI's use of QR codes does not change anything else about the key-signing process, though. The QR code captured by the camera is decoded to text for the user's inspection, so in practice it must encode the same hex fingerprint that one would otherwise provide as a command-line argument to GnuPG. That is to say, no new attacks are made possible by hiding payloads in QR codes and using Monkeysign than are possible with GnuPG or any other key-signing utility.
The automatic-email step, similarly, is a slight deviation from standard practice, but one that—hopefully—has real-world benefits. After signing a key, GnuPG can either upload the signed key directly to a keyserver or it can save it to file locally. Generally speaking, the best practice (at least on some security counts) is for the user to save the signature to a file, then send it to the owner of the other key as an email attachment. Sending the file to the address associated with the key ensures that the signature goes to whoever actually controls the email address, and it allows the key owner to control whether or not the signature is published for the rest of the world to see.
Best practices, however, are not always followed. Users can forget to send the email, send it to the wrong address, or even lose the file. Automating the process simply makes such errors less likely. Monkeysign does require that there be a working method to send the email. The default is to use sendmail, but the convenient option of sending mail via an account on an SMTP server is also supported—all of the relevant credentials can be provided as command-line arguments. And, for those times when a server (or Internet connectivity in general) are not available, the --no-mail switch can be used to disable the email step entirely.
It is also worth noting that not every user wants to receive key signatures via email, so switching off this functionality can be important for those cases as well. Finally, the --local switch is also supported, allowing users to create non-exportable signatures (that is, signatures which are marked so that they should not be exported and uploaded to public keyservers), just like GnuPG and other tools.
Improvements and impact
Beaupré stated in the 2.0 release notes that the main impetus for the new version was to get Monkeysign's reworked GUI interface into the jessie release. The 2.0 version is not significantly different on the outside than the 1.x-era interface, although it does allow the user to easily choose between multiple video devices if there is more than one webcam attached.
One functional change is introduced in the new release, however. QR codes can now be imported from image files as well as from an attached webcam. This is good news for anyone whose primary computer does not have a built-in camera facing a convenient direction, as well as for anyone who tires of holding their laptop up to scan the QR code on someone else's laptop screen.
The difficult thing in assessing the importance of Monkeysign—or of any other effort to make OpenPGP more palatable—is that it requires speculation. There seems to be very little real-world usability testing of public-key cryptography tools, despite the fact that improving usability is such a major concern. QR codes should make key-exchange and key-signing easier, but it is hard to guess how such a change would actually impact usage numbers.
Perhaps Monkeysign alone is not enough to make an impact, and only when most or all OpenPGP implementations support QR codes would any real difference be seen. There are a few other QR-code–aware tools, such as GnuPG for Android, but the idea is far from universal.
Although it is not explicitly stated, there is one other possible advantage to be found in presenting QR codes rather than hexadecimal fingerprints to other OpenPGP users: for some people, a "visual hash" is simply preferable to reading lengthy, unbroken strings of random characters. Whether spotting mismatched QR codes is easier for the average user than spotting mismatched hex strings is harder to say, but this is akin to the idea behind OpenSSH's use of randomart images (which, in turn, inspired Aaron Toponce's randomart for OpenPGP project).
On the whole, perhaps it is safest to say that using Monkeysign (especially the GUI version) provides a moderate practical difference in ease-of-use, but it could provide a major perceptual difference for users not accustomed to OpenPGP. Like it or not, reliance on command-line-only interfaces frequently contributes to the perception that a technology is old-fashioned. For some non-zero portion of the population, at least, the idea that software is old-fashioned is enough to dissuade them from using it—perhaps, in some cases, merely because it is not trendy, but in other cases, users may rightly suspect that outdated security technology is unreliable.
At least with QR support and close-to-automatic notifications, OpenPGP seems more like a technology that is still actively developed, not a relic stuck firmly in 1991. So it is valuable that Monkeysign enables OpenPGP user to manipulate trendy new formats like QR codes, even if the underlying key-signing process remains the same.
That said, Monkeysign's ability to attract new users clearly has limits. It still assumes that the user has created an OpenPGP key pair in the first place—and persuading new users to cross that bridge to begin with is perhaps the largest obstacle. It would be interesting to see whether Monkeysign would be well-received when coupled with other OpenPGP-simplification projects, such as STEED's automatic key generation.
But it is hard to see any negative impact that Monkeysign would have on OpenPGP usage. Perhaps it is only a baby step forward in usability, but there is plenty of room for forward progress where the usability of public-key encryption is concerned.
Brief items
Security quotes of the week
One NTPD to rule them all,I am going to guess the serious time distribution people are in control of this software stack, but 99% of their base is in the edge devices where the extra complexity is unwarranted? (Is it time for a coup?)
One NTPD to find them,
One NTPD to bring them all
and on the internet hole them
What we have is a very extreme case of hacking. By "extreme" I mean the quantity of the information stolen from Sony's networks, not the quality of the attack. The attackers seem to have been good, but no more than that. Sony made its situation worse by having substandard security.
Git v2.2.1 (security release) available
There is a new version of the Git client out with an important security fix: with vulnerable versions of the Git client on a case insensitive filesystem, it is possible for a pull from a repository to overwrite the .git directory and cause the execution of arbitrary commands. Linux systems running normal filesystems are not affected by this problem, but Windows and Mac OS systems are.Severe NTP vulnerabilities
Here is a CERT advisory warning of a number of code-execution vulnerabilities in the network time protocol (NTP) implementation. "These vulnerabilities could be exploited remotely. Exploits that target these vulnerabilities are publicly available." Most distributors already have updates available; applying them seems like a good idea.
New vulnerabilities
docuwiki: cross-site scripting
| Package(s): | docuwiki | CVE #(s): | CVE-2014-9253 | ||||||||
| Created: | December 22, 2014 | Updated: | December 24, 2014 | ||||||||
| Description: | From the Mageia advisory:
Our current dokuwiki-20140929-1.1.mga4 package uses dokuwiki-2014-09-29a source which allows swf (application/x-shockwave-flash) uploads by default. This may be used for Cross-site scripting (XSS) attack which enables attackers to inject client-side script into Web pages viewed by other users. | ||||||||||
| Alerts: |
| ||||||||||
eglibc: denial of service
| Package(s): | eglibc | CVE #(s): | CVE-2014-9402 | ||||||||||||||||||||||||||||||||
| Created: | December 23, 2014 | Updated: | December 24, 2014 | ||||||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory:
Avoid infinite loop in nss_dns getnetbyname | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
file: denial of service
| Package(s): | file | CVE #(s): | CVE-2014-8116 CVE-2014-8117 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2014 | Updated: | January 9, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
Thomas Jarosch of Intra2net AG reported that using the file command on a specially-crafted ELF binary could lead to a denial of service due to uncontrolled resource consumption (CVE-2014-8116). Thomas Jarosch of Intra2net AG reported that using the file command on a specially-crafted ELF binary could lead to a denial of service due to uncontrolled recursion (CVE-2014-8117). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
freetype: buffer overflow
| Package(s): | freetype | CVE #(s): | CVE-2014-9659 | ||||||||||||||||||||||||||||
| Created: | December 24, 2014 | Updated: | March 30, 2015 | ||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
It was reported that Freetype before 2.5.4 suffers from an out-of-bounds stack-based read/write flaw in cf2_hintmap_build() in the CFF rasterizing code, which could lead to a buffer overflow. This is due to an incomplete fix for CVE-2014-2240. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
git: code execution
| Package(s): | git | CVE #(s): | CVE-2014-9390 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 24, 2014 | Updated: | August 27, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
It was reported that git, when used as a client on a case-insensitive filesystem, could allow the overwrite of the .git/config file when the client performed a "git pull". Because git permitted committing .Git/config (or any case variation), on the pull this would replace the user's .git/config. If this malicious config file contained defined external commands (such as for invoking an editor or an external diff utility) it could allow for the execution of arbitrary code with the privileges of the user running the git client. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
jasper: two code execution vulnerabilities
| Package(s): | jasper | CVE #(s): | CVE-2014-8137 CVE-2014-8138 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 19, 2014 | Updated: | January 14, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
A heap-based buffer overflow flaw was found in the way JasPer decoded JPEG 2000 image files. A specially crafted file could cause an application using JasPer to crash or, possibly, execute arbitrary code. (CVE-2014-8138) A double free flaw was found in the way JasPer parsed ICC color profiles in JPEG 2000 image files. A specially crafted file could cause an application using JasPer to crash or, possibly, execute arbitrary code. (CVE-2014-8137) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: two vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2014-8559 CVE-2014-8133 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2014 | Updated: | November 4, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
The d_walk function in fs/dcache.c in the Linux kernel through 3.17.2 does not properly maintain the semantics of rename_lock, which allows local users to cause a denial of service (deadlock and system hang) via a crafted application. (CVE-2014-8559) From the Red Hat bugzilla: It was found that espfix functionality (when returning to userspace with a 16 bit stack, the CPU will not restore the high word(s) of stack pointer for us on executing iret and thus potentially leaks kernel addresses; espfix fixes this) can be bypassed by installing 16-bit RW data segment into GDT instead of LDT (which espfix checks for) and using it for stack. A local unprivileged user could potentially use this flaw to leak kernel stack addresses. (CVE-2014-8133) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
krb5: NULL dereference
| Package(s): | krb5 | CVE #(s): | CVE-2014-5353 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2014 | Updated: | June 22, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
In MIT krb5, when kadmind is configured to use LDAP for the KDC database, an authenticated remote attacker can cause a NULL dereference by attempting to use a named ticket policy object as a password policy for a principal. The attacker needs to be authenticated as a user who has the elevated privilege for setting password policy by adding or modifying principals. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
mantis: multiple vulnerabilities
| Package(s): | mantis | CVE #(s): | CVE-2014-9280 CVE-2014-9279 CVE-2014-6316 CVE-2014-9117 CVE-2014-9089 | ||||||||||||||||
| Created: | December 22, 2014 | Updated: | December 24, 2014 | ||||||||||||||||
| Description: | From the CVE entries:
The current_user_get_bug_filter function in core/current_user_api.php in MantisBT before 1.2.18 allows remote attackers to execute arbitrary PHP code via the filter parameter. (CVE-2014-9280) The print_test_result function in admin/upgrade_unattended.php in MantisBT 1.1.0a3 through 1.2.x before 1.2.18 allows remote attackers to obtain database credentials via a URL in the hostname parameter and reading the parameters in the response sent to the URL. (CVE-2014-9279) MantisBT before 1.2.18 uses the public_key parameter value as the key to the CAPTCHA answer, which allows remote attackers to bypass the CAPTCHA protection mechanism by leveraging knowledge of a CAPTCHA answer for a public_key parameter value, as demonstrated by E4652 for the public_key value 0. (CVE-2014-9117) Multiple SQL injection vulnerabilities in view_all_bug_page.php in MantisBT before 1.2.18 allow remote attackers to execute arbitrary SQL commands via the (1) sort or (2) dir parameter to view_all_set.php. (CVE-2014-9089) From the Red Hat bugzilla: A bug in the URL sanitization routine allows an attacker to craft an URL that can redirect outside of the MantisBT instance's domain when the software is installed at the web server's root. (CVE-2014-6316) | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
mediawiki: cross-site scripting
| Package(s): | mediawiki | CVE #(s): | |||||||||||||||||||||
| Created: | December 24, 2014 | Updated: | December 29, 2014 | ||||||||||||||||||||
| Description: | From the Debian advisory:
A flaw was discovered in mediawiki, a wiki engine: thumb.php outputs wikitext messages as raw HTML, potentially leading to cross-site scripting (XSS). | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
ntp: multiple code execution vulnerabilities
| Package(s): | ntp | CVE #(s): | CVE-2014-9293 CVE-2014-9294 CVE-2014-9295 CVE-2014-9296 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2014 | Updated: | January 29, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CERT advisory:
Google Security Team researchers Neel Mehta and Stephen Roettger have coordinated multiple vulnerabilities with CERT/CC concerning the Network Time Protocol (NTP). As NTP is widely used within operational Industrial Control Systems deployments, NCCIC/ICS-CERT is providing this information for US Critical Infrastructure asset owners and operators for awareness and to identify mitigations for affected devices. ICS-CERT may release updates as additional information becomes available. These vulnerabilities could be exploited remotely. Exploits that target these vulnerabilities are publicly available. Products using NTP service prior to NTP-4.2.8 are affected. No specific vendor is specified because this is an open source protocol. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
pam: two vulnerabilities
| Package(s): | pam | CVE #(s): | CVE-2014-2583 CVE-2013-7041 | ||||||||||||||||||||||||
| Created: | December 18, 2014 | Updated: | May 13, 2015 | ||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entries:
CVE-2014-2583: Bug If attacker can control PAM_RUSER or PAM_TTY item and pam_timestamp is "sufficient", (it makes sense to have it sufficient, as it aims to mimic sudo timestamp tickets and is suggested so in the man page) they can bypass authentication. PAM_RUSER is set in vsftpd or sssd for example. PAM_TTY can be set via dbus in gdm's x11-display variable. That has the following impact: 1. For authentication, this can allow to bypass the auth process, depending on interal app logic and the existance of certain root owned files (the file size is checked to match certain value, but chances are that such files exist somewhere under /). For openssh, if accidently included via auth-common, this can be dangerous, as the PAM_TTY is always set to "ssh". However due to PAM_TTY_KLUDGE #ifdef and internal sshd logic this probably is no issue as of today. 2. When a vector is also handling pam sessions (sssd), this bug also allows to create arbitrary files when the timestamp file is created and I guess content can be crafted with so much love to create fake shadow-file entries is possible. One should probably take care to not accidently include pam_timestamp in a config file for a remote service, as chance is high that the RUSER/TTY is used incorrectly, even when the user string is checked via getpwnam(). It should probably be documented in pam_timestamp's manpage. CVE-2013-7041: Bug It was found that in pam_userdb module for PAM, password hashes weren't compared case-sensitively, which could lead to acceptance of hashes for completely different passwords, which shouldn't be accepted. After hashing the user's password with crypt(), pam_userdb compares the result to the stored hash case-insensitively with strncasecmp(), which should be avoided, as it could result in an increased possibility of a successful brute-force attack. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
php: code execution
| Package(s): | php | CVE #(s): | CVE-2014-8142 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2014 | Updated: | January 5, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mageia advisory:
A use-after-free flaw was found in PHP unserialize(). An untrusted input could cause PHP interpreter to crash or, possibly, execute arbitrary code when processed using unserialize(). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
pyxdg: symlink attacks
| Package(s): | pyxdg | CVE #(s): | CVE-2014-1624 | ||||||||||||
| Created: | December 22, 2014 | Updated: | January 5, 2015 | ||||||||||||
| Description: | From the CVE entry:
Race condition in the xdg.BaseDirectory.get_runtime_dir function in python-xdg 0.25 allows local users to overwrite arbitrary files by pre-creating /tmp/pyxdg-runtime-dir-fallback-victim to point to a victim-owned location, then replacing it with a symlink to an attacker-controlled location once the get_runtime_dir function is called. | ||||||||||||||
| Alerts: |
| ||||||||||||||
sagemath: cross-site scripting
| Package(s): | sagemath | CVE #(s): | CVE-2012-4230 | ||||||||||||||||
| Created: | December 22, 2014 | Updated: | January 6, 2015 | ||||||||||||||||
| Description: | From the CVE entry:
The bbcode plugin in TinyMCE 3.5.8 does not properly enforce the TinyMCE security policy for the (1) encoding directive and (2) valid_elements attribute, which allows attackers to conduct cross-site scripting (XSS) attacks via application-specific vectors, as demonstrated using a textarea element. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
sox: code execution
| Package(s): | sox | CVE #(s): | CVE-2014-8145 | ||||||||||||||||||||||||
| Created: | December 24, 2014 | Updated: | December 12, 2016 | ||||||||||||||||||||||||
| Description: | From the Debian advisory:
Michele Spagnuolo of the Google Security Team discovered two heap-based buffer overflows in SoX, the Swiss Army knife of sound processing programs. A specially crafted wav file could cause an application using SoX to crash or, possibly, execute arbitrary code. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
subversion: denial of service
| Package(s): | subversion | CVE #(s): | CVE-2014-3580 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 22, 2014 | Updated: | December 24, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Evgeny Kotkov discovered a NULL pointer dereference while processing REPORT requests in mod_dav_svn, the Subversion component which is used to serve repositories with the Apache web server. A remote attacker could abuse this vulnerability for a denial of service. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
subversion: denial of service
| Package(s): | subversion | CVE #(s): | CVE-2014-8108 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | December 24, 2014 | Updated: | December 24, 2014 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
The mod_dav_svn Apache HTTPD server module in Apache Subversion 1.7.x before 1.7.19 and 1.8.x before 1.8.11 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a request for a URI that triggers a lookup for a virtual transaction name that does not exist. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
unrtf: code execution
| Package(s): | unrtf | CVE #(s): | CVE-2014-9274 CVE-2014-9275 | ||||||||||||||||||||||||
| Created: | December 23, 2014 | Updated: | July 7, 2015 | ||||||||||||||||||||||||
| Description: | From the CVE entries:
UnRTF allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code as demonstrated by a file containing the string "{\cb-999999999". (CVE-2014-9274) UnRTF allows remote attackers to cause a denial of service (out-of-bounds memory access and crash) and possibly execute arbitrary code via a crafted RTF file. (CVE-2014-9275) | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
znc: denial of service
| Package(s): | znc | CVE #(s): | CVE-2014-9403 | ||||||||||||||||||||
| Created: | December 19, 2014 | Updated: | December 2, 2015 | ||||||||||||||||||||
| Description: | From the ZNC bug report:
Adding an already existing channel to a user/network via web admin causes a crash if the channel name isn't prefixed with '#' (i.e you already have a channel '#potato' but you try to add 'potato' without the '#' prefix). This only appears to happen if the channel is already in the list and not if you are adding a new channel that isn't already in the list. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>
