The recently released version 4.7.2 of WordPress had an additional security fix which was not disclosed in the changelog when it was released. The issue? A privilege escalation / content injection bug in the REST API that allowed for the potential that anyone could edit any post.
Part of the REST API had an improper check for a valid post. If it was not a valid post ID but still contained a valid ID within a string such as “134A” it would be converted to an integer (the A gets stripped away making it just “134”) which gives any user access to update the post via shortcodes (and possibly other routes).
This issue was fixed in 4.7.2 so make sure your WordPress install is updated!
Last week WordPress released the second security update for version 4.7. There were 3 security issues fixed:
- Interface for assigning taxonomy terms in Press This was shown to users who did not have permission
- An SQL injection vulnerability was patched in the WP_Query class to prevent poorly coded plugins and themes from falling victim (involving post types)
- Fixed a cross-site scripting (XSS) vulnerability in the post listing table (excerpts were not being escaped)
It is strongly encouraged that, if you are not using an automated update system, you manually update/upgrade your version of WordPress to this latest to prevent exploitation.
As browsers continue to add new features, many of them need to notify or request confirmation from the user. These notifications and dialogs are showing outside the browser interface and appear inside or overtop of the content window (considered to be untrusted since any content can be displayed by developers). This means that content developers can mimic these notifications easier and trick (or bait/phish) users into clicking or submitting information to dialogs that are not part of the browser.
A family member was recently subject to something very similar last week. The browser was being forced into fullscreen mode. Popups were repeatedly sent to prevent being able to do anything else with the browser. Whenever I hit F11 to exit fullscreen mode, it immediately went back into fullscreen mode. At the same time the browser’s interface (address bar, tabs, bookmarks, etc.) could have been faked within that full screen browser tab. Since many browsers today use the same or similar technology to render their interfaces it can be easily mimicked using HTML & CSS. Luckily I was able to prevent the popups and close the browser window using Ctrl + W. An simple [may not be perfect] fix for this is to require requesting the user approve going to fullscreen in cases other than for the video tag – similar to how the user’s location must be requested.
These encroachments have security researchers worried because it means that none of the browser window can be trusted and phishing schemes / scams will likely become increasingly successful when the user believes they are interacting with the browser when they are really interacting with the content of a potentially malicious website.
PHP has released security updates for versions 7, 7.1, and 5.6. Since these are security releases it is HIGHLY recommended you update to them. I also heavily recommend you update to them as there are some odd bugs fixed in earlier versions for rare cases that could cause hangs or segfaults (crashes) in some cases where minor coding errors are made.
Highlights for Version 5.6.30
- An issue was fixed where a TIFF or JPEG with malicious or invalid metadata tag can cause PHP to terminate prematurely on Intel CPUs (not necessarily a security issue but could break some code)
- Use-after-free memory access for images passed as an input argument to a GD image output function
- Fixed a DOS vulnerability in gdImageCreateFromGd2Ctx()
- Fixed integer overflow in gd_io.c
- Fixed an issue where a hostile or corrupt compressed PHAR file could leak memory, corrupt memory, or crash PHP
- Fixed issue where, under certain cases, a hostile serialized string could be used to access freed memory (use-after-free)
- Fixed an issue where a hostile serialized string can read out-of-bounds memory
While some of these issues require specific cases, there also appears to be some easily utilized security issues where proper input sanitization is not met as well as some possible image upload security issues.
Highlights for Version 7.0.15
- Fixed a few of the same serialized string issues fixed in version 5.6.30
- Fixed issue where for each value parameter passed back as reference where no reference exists causes a crash
- Fixed issue where unpacked arrays do not properly advance using next()
- Fixed null pointer dereference under certain conditions when unpacking serialized object
- Fixed an issue where, with maliciously crafted code, a read-after-free can occur with the properties storage table when unserializing objects which could allow an attacker to execute arbitrary code
- Fixed the same GD and EXIF metadata issues that were fixed in version 5.6.30
- Fixed memory leak in preg_*() regular expression functions
- Fixed same PHAR issues that were fixed in version 5.6.30
- Fixed reflection class stored as object property not being properly freed/destroyed when the class is destroyed (memory leak)
- Fixed crash where object with __sleep() method is serialized
- Fixed issue where get_browser() runs slow/longer under certain conditions or loading browsercap.ini uses a lot of memory at startup
- Fixed issue where get_defined_functions() returned functions that were disabled via settings/php.ini
Essentially, __wakeup and serialized strings and objects have become a target for hostile intent. This is a fairly large security issue since many libraries and CMSes use serialized data and many pieces of code utilize the wakeup method – even if hostile intent needs to be done under certain conditions which many not occur very often.
Highlights for Version 7.1.1
- Majority of the same issues fixed in 7.0.15 were also fixed in this version
Since 7.1 shares a very similar codebase to 7.0.x, there were not any additional bugs that stood out to me other than those that were fixed as part of version 7.0.15 that were also fixed in this version.
WordPress, the open-source blogging and CMS platform, has released version 4.7.1, a security update to version 4.7.
The update fixes eight (8) major security issues as well as sixty-two (62) other various bugs found in 4.7.
- Remote code execution (RCE) in PHPMailer – No specific issue appears to affect WordPress or any of the major plugins we investigated but, out of an abundance of caution, we updated PHPMailer in this release.
- The REST API exposed user data for all users who had authored a post of a public post type. WordPress 4.7.1 limits this to only post types which have specified that they should be shown within the REST API.
- Cross-site scripting (XSS) via the plugin name or version header on update-core.php.
- Cross-site request forgery (CSRF) bypass via uploading a Flash file.
- Cross-site scripting (XSS) via theme name fallback.
- Post via email checks mail.example.com if default settings aren’t changed.
A cross-site request forgery (CSRF) was discovered in the accessibility mode of widget editing.
- Weak cryptographic security for multisite activation key.
It is strongly encouraged that you update your version of WordPress as soon as possible to avoid possible exploitations. As always, I also encourage everyone to read through the changelog to see what was fixed or what could be a potential issue in the future.
Google Chrome version 56 (based on the open-source Chromium web browser) is scheduled to be released at the end of the month. One of the major user-level changes is how sites without encryption will appear. Until now there has just been a lowercase letter “i” with a circle around it — this was typically an indicator to get more information about the site. In the upcoming version this symbol will be accompanied by a “not secure” message to indicate that the site is not secure:
Google has also indicated that future versions of Chrome will continue to make sites that are not encrypted appear with a more prominent warning symbol:
Google warned about this back in September of 2016.
The domain name service (DNS) and security proxy provider Cloudflare appears to have tripped over the leap second at the end of 2016. The Go programming language that is uses to build it’s DNS server apparently returned a negative number for the date in some cases which caused the random number generator to throw errors. The fix? A single line of code where less than or equal to zero (<=0) is used instead of simply equal to zero (==0).
The Electronic Frontier Foundation (EFF) reported that the number of websites utilizing encryption (HTTPS) to secure the traffic between the browser and the web server. For the first time since the inception of the Internet, the majority (more than half) of internet traffic was encrypted! It did not matter the size: large and small websites have been adopting secure certificates to encrypt their traffic… but why?
A number of factors played out over the past year that lead to this mass migration to encryption. Google announced it would start giving sites a small rank boost if they used encryption (that will likely get stronger as time goes on), web browsers adding visual features that make non-encrypted sites look less secure, increasing pressure from governments, businesses, and the public to secure the net, the addition of some new and advanced browser features that only work on encrypted connections, and the introduction of free programmatic (automated) secure certificates all lead to the massive adoption that occurred throughout the year.
There are still a number of countries, particularly in Asia and the Middle East, that are resisting the adoption of encryption but various organizations are already looking into how they can encourage the holdouts to join in.
Personally I see this as no different than when much of the world, especially those in the east, continued to rely on the old, out-of-date Internet Explorer versions and were eventually pressured to upgrade by Microsoft along with various other organizations through various advertisements and public service announcements (PSAs, but maybe Internet Service Announcements?). They showed just how insecure & slow older browsers are and how much risk is taken by refusing and/or blocking browser upgrades.
A new Remote Code Execution (RCE) vulnerability has been reported on Christmas but details were only recently released. PHPMailer has already issued a patch (though they are not 100% confident in it), and WordPress (which uses PHPMailer) is considering issuing a security patch for current versions as well.
The vulnerability allows the FROM address, when passed as a variable into into PHPMailer with escaped shell arguments, will be passed to the mail function and allows an attacker to put executable code into the root.’
Note that as of now there are no known working exploits for this. Also note that this exploit may not work on all systems due to different mail functions being used having different arguments available.
Also, as long as the email address passed to the FROM variable is more strictly validated (not allowing the escaped quotes and whitespace in email addresses), it is not an issue. Some feel that the strictness of not following the RFC exactly will prevent valid emails but many point out that it would only block VERY FEW valid emails and argue that the RFC should not allow such characters – most well-known email systems do not allow such characters anyway.
The code that I write always validates the email using the filter_var function (which is strict and prevents the issue from occuring). I checked Gravity Forms and they also use the filer_var function. I don’t know about JetPack. It is also likely that, if they have not already, CloudFlare and WP Engine will add an input filter for this.
If you are using a custom build of PHPMailer in any extensions/add-ons or external code is is HIGHLY RECOMMENDED that you upgrade to PHPMailer version 5.2.18 or newer which has escaping added to the FROM address.