Class 'getid3_handler' not found

[manjeetwp681]

I'm getting this issue multiple time in my kibana logs, from past 5 months we are getting the same issue.

​https://prnt.sc/r6tddw

[ocean90]

Hello @manjeetwp681, welcome to WordPress Trac!

Thanks for your report. The class is defined in ​https://build.trac.wordpress.org/browser/tags/5.3.2/wp-includes/ID3/getid3.php#L1859 and the file is included in wp_read_video_metadata() and wp_read_audio_metadata(). Can you check if your getid3.php looks the same as the above? Do you have plugins enabled related to media handling? Please try disabling them to see if the error remains.

[siliconforks]

I've seen this message appear in the error log too.

It appears to be coming from a hack attempt probing for various files in the WordPress installation, one of which is the module.audio.ac3.php file:

xxx.xxx.xxx.xxx - - [23/Feb/2020:12:35:33 -0800] "GET /wp-includes/ID3/module.audio.ac3.php HTTP/1.1" 500 3467 "-" "python-requests/2.22.0"

Obviously this fails with the error message above. I don't know why the attacker is probing for that particular file.

[ocean90]

#49548 was marked as a duplicate.

[carl-alberto]

It seems this is related to a couple of files included in the wp core from the getID3 lib ​https://github.com/JamesHeinrich/getID3

Steps to reproduce the error:

1) Error logging/debugging is enabled in a WP site and the host allows it
2) Visit directly the location of the said files eg: ​https://example.com/wp-includes/ID3/module.audio-video.asf.php it will give out the error Fatal error: Uncaught Error: Class 'getid3_lib' not found in wp-includes/ID3/module.audio-video.asf.php:16 Stack trace: #0 {main} thrown in wp-includes/ID3/module.audio-video.asf.php on line 16

Affected files
These are the files affected in the WP core in this folder wp-includes/ID3/

module.audio-video.asf.php
module.audio-video.flv.php
module.audio-video.matroska.php
module.audio-video.quicktime.php
module.audio-video.riff.php
module.audio.ac3.php
module.audio.dts.php
module.audio.flac.php
module.audio.mp3.php
module.audio.ogg.php
module.tag.apetag.php
module.tag.id3v1.php
module.tag.id3v2.php
module.tag.lyrics3.php

This vulnerability is the hosting's responsibility

Most technical users know that the path disclosure is the hosting's responsibility to address this issue but let's put our shoes in a simple user that is not very technical and can only host from the cheapest possible way where there is no staging and they always work in a live site where by default debugging is on, it would affect the user-friendliness of an application as most likely they will run into:

• the full path is exposed by default and their site will be a favorite target for SQLI attacks and automated probes before the owners know it
• their disk space can be maxed out when the error logs piles up
• this user will need to hire a developer to get this coordinated to the hosting to get this turned off if he is not familiar in toggling the settings from the host

Possible long term solution

Opened up an issue here in the getID3 lib ​https://github.com/JamesHeinrich/getID3/issues/235 and added a patch ​https://github.com/JamesHeinrich/getID3/pull/236 Hopefully this will be put into consideration and merged in the WP core eventually

[ocean90]

I have contacted some hosting providers are they have confirmed seeing similar requests. All requests where using a python-requests user agent. It looks like this file is now included in a script for backdoor check requests.

As this sort of error can happen with most of the files in wp-includes I suggest to take a look at the ​Hardening WordPress support document, particularly the ​Securing wp-includes section.

[Sudavar]

Hello,

the merge request of @carl-alberto (​https://github.com/JamesHeinrich/getID3/pull/236) was accepted into the getID3 lib repo, perhaps it could also be included in the next version of WordPress as well?

[DrLightman]

I've seen this Fatal Error passing by my logs today too.

Being WordPress open source it's not difficult to target and load PHP files one by one in the browser after you've downloaded the zip, opened it and learnt of which files is made of.

Maybe it would make sense to put something like:

<?php
if ( ! defined( 'ABSPATH' ) ) {
    die( 'Meh' );
}

On top of all files that are not index.php or are not meant to be called directly?

[jasonpiersonawana]

Any word on this being merged into core? We're getting these errors multiple times a day. I saw @ocean90 's comment about hardening, which is blocking those scripts using mod_rewrite in the .htaccess file. However, our host(Pantheon), ignores the .htaccess file.

[carl-alberto]

@jasonpiersonawana Pantheon is Nginx based so .htaccess won't work but as a platform mitigation, you can add those paths as a protected path in the pantheon.yml file so they cannot be accessed directly. Please see this guide ​https://pantheon.io/docs/pantheon-yml#protected-web-paths. Thanks!

[SergeyBiryukov]

Replying to jasonpiersonawana:

Any word on this being merged into core? We're getting these errors multiple times a day.

In [48278] / #49945 getID3() was updated to version 1.9.20, which includes the ​PR mentioned above.

[jasonpiersonawana]

@SergeyBiryukov, thanks for the update! Exciting!

[carl-alberto]

Thanks @SergeyBiryukov, glad to hear that this is going into core :)