Ubuntu 18.04 LTS (Bionic Beaver) is out today, after a short delay caused by a last-minute bug. The 18.04 release has been highly anticipated, since it is the first long-term-support (LTS) release since the switch back to GNOME as the default desktop environment for Ubuntu and the abandonment of Unity. Along with the glamour of a new desktop environment, 18.04 brings a new kernel, updated software packages, five years of support, and a multitude of other improvements. The new release also brings some controversy in the form of a new network manager. You can read the full release notes here, and you can grab Xubuntu 18.04, Kubuntu 18.04, Lubuntu 18.04, or any of the multitude of similarly updated Ubuntu variants.

The author has not tested 18.04 yet, but intends to do so as soon as he is finished messing about with CentOS and can be bothered to spin up a virtual machine.

The proximity sensor on several iPhone models appears to have been temporarily affected by the iOS 11.3 update released in March this year. The proximity sensor, which is located near the earpiece and the front-facing camera, is supposed to detect when the phone has been placed near a user’s ear so that the screen can be blanked to prevent unwanted touch input. However, after the iOS 11.3 update, some proximity sensors appear to be constantly stuck on, causing the screen to go black even when the phone is not engaged in a call.

I confirmed the issue on my iPhone 7 after trying to figure out why the screen was randomly turning black. You guessed it: I was placing my finger over the proximity sensor by mistake. Upon further investigation, it turned out that I could replicate the strange behavior in any app and even on the home screen.

The Fix: Force Restart

Fortunately, a force restart fixed the proximity sensor issues, even though a regular shutdown/restart did not. To force restart your iPhone, refer to Apple’s help page on the subject:

iPhone X or iPhone 8

Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then, press and hold the Side button until you see the Apple logo.

iPhone 7

Press and hold both the Side and Volume Down buttons for at least 10 seconds, until you see the Apple logo.

iPhone 6s and older

Press and hold both the Home and the Top (or Side) buttons for at least 10 seconds, until you see the Apple logo.

The Forums Agree

It appears the proximity sensor issue has already made an appearance on the Apple forums:

• issue with proximity sensor after ios 11.3 update
• iphone x proximity sensor always on?
• can i adjust proximity sensor settings?
• proximity sensor on all the time after update to 11.3 help !

Since WordPress is such a popular website platform (a.k.a. Content Management System, or CMS), there’s a multitude of different ways to misconfigure it. Consequently, there’s also someone out on the Internet who will attempt to exploit every possible misconfiguration in your WordPress installation. This time on Server Logs Explained we’ll be looking at one such attempt, albeit a fairly basic one.

The Logs

WordPress sites get random requests all the time for pages that should normally be off-limits to the outside world, which brings us to today’s log excerpt:

203.0.113.42 - - [19/Jun/2016:07:37:57 -0400] "GET /wp-admin/post-new.php HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0"

This hardly borders on an attempted exploit, since it’s just a plain HTTP GET request for the post-new.php page. However, if you’re still getting familiar with WordPress’s file structure, it can be a good learning experience to examine some of the unexpected requests your server gets.

Call and Response

First, let’s see what happened next, since the server returned a 302 Found (moved temporarily) response code. A 302 response generally provides the client with an alternate URL it should try instead:

203.0.113.42 - - [19/Jun/2016:07:37:57 -0400] "GET /wp-login.php?redirect_to=http%3A%2F%2Fwww.example.com%2Fwp-admin%2Fpost-new.php&reauth=1 HTTP/1.1" 200 1307 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0"

In plain English, the server politely asked the client to try wp-login.php instead, and the client followed the redirect.

This is exactly what’s supposed to happen, because post-new.php is the admin page that allows a site author to create a new post. Like the other admin pages in the /wp-admin/ directory, it should only be accessible to users who are logged in and have the permission to create new posts. If an unauthenticated user tries to access an admin page, WordPress is supposed to redirect them to the login page so that they can authenticate (or not).

Bonus Section: A Little Information About Query Strings

The most interesting part of this exchange is the request to wp-login.php, so let’s examine that. Stripping away the extra information from the second log excerpt leaves us with the request the client made to wp-login.php:

GET /wp-login.php?redirect_to=http%3A%2F%2Fwww.example.com%2Fwp-admin%2Fpost-new.php&reauth=1 HTTP/1.1

The first part, GET, is the HTTP method used (as opposed to POST, etc.). Check out Mozilla’s HTTP request methods documentation if you are curious about other methods defined in the HTTP standard. The last part, HTTP/1.1, is the version of HTTP that was used between the client and the server, so we can skip that as well.

The middle part is the request the client made to wp-login.php, and it includes an interesting query string. The query string begins with ? and looks like this:

?redirect_to=http%3A%2F%2Fwww.example.com%2Fwp-admin%2Fpost-new.php&reauth=1

Query strings are one way to allow data to be passed to a webpage. This is useful if your webpage is coded in a dynamic language, like PHP, and can accept input. This particular query string contains two pieces of data, separated by the & character:

1. redirect_to, a string, and
2. reauth, a value.

The data contained in the request is highlighted in the following example:

?redirect_to=http%3A%2F%2Fwww.example.com%2Fwp-admin%2Fpost-new.php&reauth=1

Let’s look at each piece of data individually:

redirect_to

The URL in redirect_to is where wp-login.php will send the client to after it has successfully authenticated. If you examine the WordPress source code, you can locate the section in the wp-login.php that handles the redirection logic.

If we clean up the URL by replacing the escaped characters with their human-readable counterparts, we can see what the full URL looks like:

http://www.example.com/wp-admin/post-new.php

In other words, after successfully authenticating, the client would have been redirected to post-new.php, which was where it was trying to go in the first place.

reauth

ReAuth is a special WordPress feature that forces the client to re-authenticate no matter what. Normally, when you sign into your WordPress site (and you have cookies enabled in your browser), you’ll stay logged in to WordPress for a certain amount of time. This is because WordPress is able to store cookies locally in your browser that indicate that you’ve already authenticated properly and shouldn’t need to log in again. However, as a safety method, if WordPress fails to detect a proper login cookie, it redirects the client to wp-login.php and forces it to re-authenticate and acquire new cookies by setting reauth=1.