1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Lack of Interest Readers & Writers

Discussion in 'Closed Suggestions' started by Jafo, Sep 23, 2010.

  1. Jafo

    Jafo Active Member

    As I am still working on this with my VB installs this suggestion may be a little incomplete.

    All software eventually has security flaws. With add-ons, this becomes even more of an issue. For example, vbseo is constantly patching holes. I administer almost 40 forums and when they start getting hacked, it creates a lot of work and costs my clients serious money. I have begun working on proactive solutions to limit attack vectors. One that we are working on now is showing promise: Create two mysql users and limit the privis of the default mysql user (default user), and give more permissive privis to the second mysql user (let's call it the admin user).

    The default user cannot write to certain tables, such as templates, plugins, settings, etc.. If the user tries, mysql throws a permissions error. So even if there is an exploit they cannot insert any code into these tables (providing they are not in the admincp). As we see with many of these hacks, one of the first things they try to do is spread their malware to the audience via the templates or plugins. If I didn't have to rely on hook locations, I could eliminate more tables (i.e. datastore).

    In my model, the admin user only connects to the database when in the admincp, or in a cron job.

    I know I am speaking in terms of vBulletin, but that is all any of us here except the staff have to illustrate this kind of suggestion. :)
     
    feldon30 likes this.
  2. Jafo

    Jafo Active Member

    OK.. That fell on deaf ears lol..
     
  3. Floris

    Floris Guest

    No, not really. I am still working on the vBulletin Audit product that scans your account passive and returns with an output of concerns and suggestions. (a 0.29 alpha is out on vborg somewhere) and suggestions like these take it a step further. I find it quite interesting!
     
    feldon30 likes this.
  4. Jafo

    Jafo Active Member

    It is coming along.. I am testing it now now on a small live site. If built into the code (instead of a plugin) it could be much more powerful. Right now I am protecting the plugin, template, and setting tables.
     
  5. Floris

    Floris Guest

    It won't prevent compromise I understand, just limits the damage - permission wise.
     
  6. cedivad

    cedivad Active Member

    I've never understood how hackers can get in so easily...
     
  7. Jafo

    Jafo Active Member

    I would not say easily.. The time we got hacked I found the exploit in vbseo. It was a pretty crafty exploit and must have taken some time to ferret out. What motivates someone to spend so much time looking for holes? Who knows...
     
  8. Floris

    Floris Guest

    9 out of 10 times because coders aren't professionals, and don't sanitize their data.
     
  9. cedivad

    cedivad Active Member

    I don't think they are just bored.
    However we will have to look at the code to know how this can be done.
    I think that if xf uses some kind of class to query the database, you can check it before the query runs and use a limited privileges users for every query that preg_match "^SELECT".
    Not sure, but usually hackers uses some kind of mysql comment to insert the bad code in the query, however if the query starts with "SELECT" you can always limit what's happening ;)
    Not even sure if i've explained.
     
  10. Jafo

    Jafo Active Member

    Well SELECT is a read function, I would be more worried about things like INSERT, UPDATE, DROP, CREATE, etc..
     
  11. cedivad

    cedivad Active Member

    As far as I know, hackers transforms a select function to an update one (example) with mysql comments.
     
  12. Jafo

    Jafo Active Member

    There is no way to "transform" it if you mean overload it somehow. They can however change a query or append to one.. Example: SELECT * FROM WHEREVER.. A hacker could: SELECT * FROM WHEREVER; INSERT INTO WHEREVER.. A MySQL user who cannot use select is dead in the water..
     
  13. cedivad

    cedivad Active Member

    That is what i tought.
    Since that xf dosen't uses this sintax:
    select *; insert *
    you can restrict the queryes that starts with select to a read only user.
     
  14. Jafo

    Jafo Active Member

    Gotcha, although I have seen queries that use selects during writes. Very infrequently though..
     

Share This Page