http://blog.ircmaxell.com/2014/10/a-lesson-in-security.html is an
interesting and thoughtful write-up on the technical details of this
vulnerability.

On Fri, Oct 31, 2014 at 12:38 PM, Joe Hourcle <[log in to unmask]
> wrote:

> On Oct 31, 2014, at 11:46 AM, Lin, Kun wrote:
>
> > Hi Cary,
> >
> > I don't know from whom. But for the heartbeat vulnerability earlier this
> year, they as well as some other big providers like Google and Amazon were
> notified and patched before it was announced.
>
> If they have an employee who contributes to the project, it's possible
> that this
> was discussed on development lists before it was sent down to user level
> mailing
> lists.
>
> Odds are, there's also  some network of people who are willing to give
> things a
> cursory review / beta test in a more controlled manner before they're
> officially
> released (and might break thousands of websites).  It would make sense that
> companies who derive a good deal of their profits in supporting software
> would
> participate in those programs, as well.
>
> I could see categorizing either of those as 'ahead of the *general*
> public',
> which was Kun's assertion.
>
> -Joe
>
>
>
> > -----Original Message-----
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Cary Gordon
> > Sent: Friday, October 31, 2014 11:10 AM
> > To: [log in to unmask]
> > Subject: Re: [CODE4LIB] Terrible Drupal vulnerability
> >
> > How do they receive vulnerability report ahead of general public? From
> whom?
> >
> > Cary
> >
> > On Friday, October 31, 2014, Lin, Kun <[log in to unmask]> wrote:
> >
> >> If you are using drupal as main website, consider using Cloudflare Pro.
> >> It's just $20 a month and worth it. They'll help block most attacks.
> >> And they usually receive vulnerability report ahead of general public.
> >>
> >> Kun
> >>
> >> -----Original Message-----
> >> From: Code for Libraries [mailto:[log in to unmask]
> >> <javascript:;>] On Behalf Of Cary Gordon
> >> Sent: Friday, October 31, 2014 9:59 AM
> >> To: [log in to unmask] <javascript:;>
> >> Subject: Re: [CODE4LIB] Terrible Drupal vulnerability
> >>
> >> This is what I posted to the Drupal4Lib list:
> >>
> >> --------------------
> >>
> >> By now, you should have seen https://www.drupal.org/PSA-2014-003 and
> >> heard about the "Drupageddon" exploits. and you may be wondering if
> >> you were vulnerable or iff you were hit by this, how you can tell and
> >> what you should do. Drupageddon affects Drupal 7, Drupal 8 and, if you
> >> use the DBTNG module, Drupal 6.
> >>
> >> The general recommendation is that if you do not know or are unsure of
> >> your server's security and you did not either update to Drupal 7.32 or
> >> apply the patch within a few hours of the notice, you should assume
> >> that your site (and server) was hacked and you should restore
> >> everything to a backup from before October 15th or earlier. If your
> >> manage your server and you have any doubts about your file security,
> >> you should restore that to a pre 10/15 image, as well or do a reinstall
> of your server software.
> >>
> >> I know this sounds drastic, and I know that not everyone will do that.
> >> There are some tests you can run on your server, but they can only
> >> verify the hacks that have been identified.
> >>
> >> At MPOW, we enforce file security on our production servers. Our
> >> deployments are scripted in our continuous integration system, and
> >> only that system can write files outside of the temporal file directory
> (e.g.
> >> /sites/site-name/files). We also forbid executables in the temporal
> >> file system. This prevents many exploits related to this issue.
> >>
> >> Of course, the attack itself is on the database, so even if the file
> >> system is not compromised, the attacker could, for example, get admin
> >> access to the site by creating an account, making it an admin, and
> >> sending themselves a password. While they need a valid email address
> >> to set the password, they would likely change that as soon as they were
> in.
> >>
> >> Some resources:
> >> https://www.drupal.org/PSA-2014-003
> >>
> >> https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-inj
> >> ection-announcement
> >>
> >> http://drupal.stackexchange.com/questions/133996/drupal-sa-core-2014-0
> >> 05-how-to-tell-if-my-server-sites-were-compromised
> >>
> >> I won't attempt to outline every audit technique here, but if you have
> >> any questions, please ask them.
> >>
> >> The takeaway from this incident, is that while Drupal has a great
> >> security team and community, it is incumbent upon site owners and
> >> admins to pay attention. Most Drupal security issues are only
> >> exploitable by privileged users, and admins need to be careful and
> >> read every security notice. If a vulnerability is publicly exploitable,
> you must take action immediately.
> >>
> >> Thanks,
> >>
> >> Cary
> >>
> >> On Thu, Oct 30, 2014 at 5:24 PM, Dan Scott <[log in to unmask]
> >> <javascript:;>> wrote:
> >>
> >>> Via lwn.net, I came across https://www.drupal.org/PSA-2014-003 and
> >>> my heart
> >>> sank:
> >>>
> >>> """
> >>> Automated attacks began compromising Drupal 7 websites that were not
> >>> patched or updated to Drupal 7.32 within hours of the announcement
> >>> of
> >>> SA-CORE-2014-005
> >>> - <https://www.drupal.org/SA-CORE-2014-005>Drupal
> >>> <https://www.drupal.org/SA-CORE-2014-005> core - SQL injection
> >>> <https://www.drupal.org/SA-CORE-2014-005>. You should proceed under
> >>> the assumption that every Drupal 7 website was compromised unless
> >>> updated or patched before Oct 15th, 11pm UTC, that is 7 hours after
> >>> the
> >> announcement.
> >>> """
> >>>
> >>> That's about as bad as it gets, folks.
> >>>
> >>
> >>
> >>
> >> --
> >> Cary Gordon
> >> The Cherry Hill Company
> >> http://chillco.com
> >>
> >
> >
> > --
> > Cary Gordon
> > The Cherry Hill Company
> > http://chillco.com
>