WP Localization (AU) files being quarantined

Home Forums BulletProof Security Pro WP Localization (AU) files being quarantined

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #34505
    bbmedia
    Participant

    WP Localization files for Australia being quarantined as of Nov 7
    /home/whisky/public_html/wp-content/languages/admin-en_AU.po
    /home/whisky/public_html/wp-content/languages/en_AU.mo
    /home/whisky/public_html/wp-content/languages/en_AU.po

    Across all my sites I currently protect with BPS Pro I have got repeated installation attempts/quarantining for the above files.

    I have not been able to confirm anywhere on the WordPress pages that the Aussie localizations have been updated, and further more wonder why an automated update would quarantine these files, so am wondering if the .mo file (which is a machine code file) is suspect. I’ve checked the text-based .po files and they seem to be legit as far as I can see, though there are quite significant differences.

    Any ideas?

    #34506
    bbmedia
    Participant

    Since I posted this, in the process of re-installing a builder plugin on one of the BPS Pro sites (where I disabled ARQ while I made the mods), I saw WordPress update the Australian localization files at the same time as the other plugin installation, so feel pretty confident that they are legit updates.

    However, this doesn’t explain why BPS Pro would not recognise a core WordPress translation update, and this probably should be addressed by AIT.

    #34508
    AITpro Admin
    Keymaster

    Ok so everything you’re doing is legit so where do you think the problem is occurrrng.

    #34509
    bbmedia
    Participant

    The problem is that core WordPress localized translation updates are being quarantined.

    #34511
    Rafael Da Costa
    Participant

    The same situation is happening with me.

    Thanks for your help

    Rafa

    #34512
    Terry Chadban
    Participant
    1. As an Aussie, I use the English Australia ‘translations’ for all websites and I can confirm that BPS Pro routinely quarantineS the .po files.
    #34513
    AITpro Admin
    Keymaster

    Sorry got caught up answering a few different questions (email, phone, forum, etc) at the same time and did not respond appropriately. The simple solution is to exclude the /languages/ folder from being checked by ARQ.

    AutoRestore|Quarantine steps for creating wp-content folder and single file exclude rules

    http://forum.ait-pro.com/forums/topic/autorestore-quarantine-guide-read-me-first/#autorestore-exclude-rules

     

    #34515
    bbmedia
    Participant

    Thanks for the exclude rules, however it was more a question put out there to determine if they were actually legit language updates, which I soon after discovered they definitely are, and the community here has confirmed this, and to alert BPS Pro so that this can be fixed for future versions. I’ll leave it with you.

    #34516
    AITpro Admin
    Keymaster

    Sorry maybe I’ve been doing this stuff too long and did not take the appropriate time to explain things in more detail.  The simple answer is this:  any files in the WP /languages/ folder are “safe” to exclude so basically it is a procedural technicality type of thing.  Absolutely safe to do and I apologize for not going into more detail.  🙂

    #34517
    bbmedia
    Participant

    Hi, maybe I haven’t been clear. We just don’t want to have to do that, because these are core file updates. That’s what this post is for – to get this fixed in a subsequent update.

    #34519
    AITpro Admin
    Keymaster

    Completely safe to exclude the WP /languages/ folder for all the right reasons.  .po and .mo files cannot be exloited and even given this case scenario; a hacker file was dumped in the WP /languages/ folder – it would be extremely difficult to launch some sort of escalating attack since ARQ IDPS monitors all other website folders. Kind of the same basic principle of the BPS Pro Plugin Firewall.  ie countermeasure containment.  We can certainly automate something like this in future version of BPS Pro by checking by file extension. Hacker code cannot be executed from a .po or .mo file, but still I like the idea of automating something like that.  Cool idea. 😉

    #34538
    bbmedia
    Participant

    I don’t really understand what you’re going on about here, and I still think you’re missing the point. These are “core” updates. You know… part of the WP core.

    I just manually updated another installation that uses BPS Pro which was waiting for these localised language files to be updated and this is the response I received after updating them:

    AutoRestore Automation Error
    AutoRestore Automation failed to backup all WP Core files during the WordPress Upgrade. AutoRestore is currently turned Off to prevent new WP Core files from being quarantined.
    Click Here to go to the Setup Wizard page. Click the Pre-installation Wizard button and the Setup Wizard button to complete the WordPress Core file backup and to turn AutoRestore back On again.

    So, I’d say, this is why the files are being quarantined unnecessarily.
    Of course running the Wizard resolves the issue, (and I see this notice sometime when I click the “return to plugin list” after an update has run, and BPS Pro hasn’t completed the autorestore backup).

    We just want core updates to run and, when they say they have finished, to not have to then do further steps to ensure that either files won’t be quarantined or we have to run the wizard again (and again, and again). When you are maintaining a lot of WP installs through a centralised interface, the last thing you want to have to do is visit each site individually to fix issues such as this.

    #34539
    AITpro Admin
    Keymaster

    WP language translation files (.po and .mo) files are automatically updated when WP automatic updates occur and whenever newer versions of .po and .mo language files are available for whichever WP language/installation version you have.  We are aware of this issue and are looking at a better solution for this known issue.  It’s a fairly complex issue, but we are looking at how to best solve this known issue.  Sorry for any inconveniences this may be causing you, but it is absolutely safe to create an ARQ folder exclude rule for the WP /languages/ folder in the meantime (this issue will be permanently fixed ASAP) > https://forum.ait-pro.com/forums/topic/language-translation-files-quarantine-wordpress-automatic-updates/

    #35237
    bbmedia
    Participant

    So… another core localisation language update, another round of quarantined files.
    Given that every time that core WP language files such as these, are updated, we have an quarantine file alert, and we have many many WP sites that we have to manage, when can we expect this to be resolved so that these WP core updates no longer are quarantined? (Also this question applies to theme error_log files which should be ignored once they have been authorised as OK by the administrator).

    public_html/wp/wp-content/languages/admin-en_AU.po

    public_html/wp/wp-content/languages/admin-en_AU.mo

    #35238
    AITpro Admin
    Keymaster

    Unfortunately, we do not think it is possible to add code to ARQ IDPS that will be able to handle WP language file automatic updates since the standard WP upgrader filters are not trigged in the same way as WP Core automatic updates.

    The simplest and best solution is to exclude the /languages/ folder from being checked by ARQ.  It is perfectly safe to exclude the WP /languages/ folder.

    AutoRestore|Quarantine steps for creating wp-content folder and single file exclude rules
    http://forum.ait-pro.com/forums/topic/autorestore-quarantine-guide-read-me-first/#autorestore-exclude-rules

    You can copy the UAEG htaccess file from the WP /uploads/ folder into the /languages/ folder if you want security protection for the /languages/ folder. The UAEG htaccess file prevents .php files and other executable files from being accessible via a Browser.

Viewing 15 posts - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.