Elgg Blog: Elgg 1.7.6 released with security enhancements

Elgg 1.7.6 has been released with important security enhancements to address a possible SQL injection attack using crafted URLs.  All 1.7 users should upgrade immediately to keep their networks and servers safe.  Thanks to Gerrit Venema from Gol Gol social community for following the security reporting guidelines and working with us to get a fix out!

In addition to security enhancements, Elgg 1.7.6 also contains a few bugfixes:

  • Pages - Fixed "All Pages" link on "All Site Pages" page.
  • Messages - Fixed invalid URLs when using old-style pg/messages/<username> links.
  • Messages - Fixed redirect after deleting a message.

For developers, two API changes are included:

  • Added get_entities_from_access_collection() and deprecated it.
  • is_registered_entity_type() returns correctly when requesting just a type and not a subtype.
Please download 1.7.6 and upgrade your site immediately.  As a reminder, all bug reports should be filed at trac and all security issues should be emailed to security [at] elgg [dot] org.
  • A comment on adding get_entities_from_access_collection() and immediately deprecating it. No, we haven't gone crazy. That function was removed incorrectly in Elgg 1.7.0 rather than being deprecated. To maintain backward compatibility, we added it back in.

  • Thanks. A nice little update this time with only 10 modified files. Upgrading worked without problems.

  • How to do I upgrade without over writing all my data /custom hacks ?


    sorry never done it before , I am 1.7.5


    should I even upgrade ?



  • Before upgrading, back up your Elgg database and code. Disable non-core plugins. Download the new version of Elgg from elgg.org. Overwrite your existing Elgg files. Any modifications should have been written within plugins, so that they are not lost on overwriting. If this is not the case, take care to maintain your modifications. Visit http://your-elgg-site-URL/upgrade.php Copy htaccess_dist to .htaccess, replacing your existing version. If you modified the default .htaccess, be sure to move your modifications over to the new one.

  • @opensource:

    It's of course up to you to decide if the benefits of upgrading are enough for you to do it. With the security risk involved in 1.7.5, I know that your database and thus your Elgg is wide open unless you have some unguessable table prefix. And even then I would not guarantee it, since it might be possible to circumvent that obstacle.

  • @Gerrit - no, your database is not wide open due to this vulnerability. It was actually quite minor if I remember all the details correctly.

  • @Cash

    I wonder if we are talking about the same vulnerability. Actually I reported the problem in 1.7.5 myself and without the fix your database is open to anyone with a browser. People can drop your tables, make themselves admin of your site and what other ideas they can come up with.

    If you can't be bothered by the risk of other people taking over your site, than no, you don't have to upgrade. It's a matter of what would be the effects of someone anonymous taking over versus the risk of this happening. Probably the chances are not high that someone would discover this by accident but you can always have the disgruntled person and it only takes one.

  • @Gerrit - let's start with a generic query:

    SELECT * FROM mytable WHERE username = '{$_GET['username']}'

    Obviously, that query is open to SQL injections. How would you drop a table though since you cannot stack queries?

  • @Cash

    Actually I thought it was easy, just insert a apostrophe, semicolon and add your other queries. I now see that this is not possible with mysql_query. PhpMyAdmin and other mysql tools generally allow you to input multiple queries separated by semicolon but mysql_query does not, contrary to what I believed.

    In the actual case of 1.7.5 it concerns an insert query however.  It would allow someone to build up values in a table where they don't belong. With subqueries you can pull administrator secrets into this table and I think I see a way to leak these values to the outside.

    So my statement that it was trivially possible to drop tables or become admin is not true. It is however possible to get data from all tables in the database into a table where it is not supposed to be and at this moment I think that with a little work it is possible to get this data to the outside. So your admin account would be vulnerable to offline brute force attacks or your session details may be hijacked. It will not exactly be trivial but doable for determined people.

    Gerrit Venema
    Gol Gol community

  • @Gerrit - ok, I remember this report now. It cannot be used to pull data out of the database as the data in that table is never exposed to a user. You can stick stuff in the table.  An admin account is not vulnerable through this though. You would need a second vulnerability to create an attack as you described.

    It is a security flaw and we highly recommend people upgrade.

  • @cash

    I hate to say it, but I think some values from this table are displayed on every Elgg site for every anonymous or non anonymous user. :)

  •   Thanks for releasing Elgg1.7.6. It's really nice, but I had a very minor problem with blog plugin which Stephen Sherman and Steve Aquila have already written in the Group discussion > blog quirks.

    Stephen Sherman wrote:

    I cannot edit the most recent post. I wrote it, saved it, and edited it once; all was fine. Now, wanting to edit it again, when I click on 'edit' for that post, the edit screen opens up, but is blank. (Not the WSOD, just the title & edit area within the blog).  A couple of older blog posts open up in the edit function normally.

      I also had the same problem. I was wondering if you could teach me how to fix it.

  • We've had exactly the same very intermittent and very occasional issue with blog post edits coming up with blank forms on our site, running 1.7.4. It has also occurred on my home server, also 1.7.4. 

    Interestingly, an admin can open and edit the same post without any problems at all but the affected user continues to get a blank form for the affected post (but not for earlier ones, that continue to work fine).

    We have tried completely clearing caches on server (both upgrade.php and turning caches off and on) and browsers, as well as using different browsers on different networks, but the problem persists, so it does not seem to be a local setting nor an /obvious/ server settings issue.

    Only occasional users are affected and only occasionally, and it apparently eventually cures itself - this is possibly caused by adding a further post but we cannot tell as it has been too intermittent and unpredictable to be able to do a controlled test yet.


Latest comments