Lücke in PCRE-Bibliothek erlaubt Remote Code Execution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Lücke in PCRE-Bibliothek erlaubt Remote Code Execution

Peer Heinlein

Aus unserem Blog
https://www.heinlein-support.de/blog/security/luecke-in-pcre-bibliothek-erlaubt-ausfuehrung-von-code/



Lücke in PCRE-Bibliothek erlaubt Ausführung von Code
Publiziert am 5. Juni 2015 von Peer Heinlein

Unser Sicherheitsspezialist Markus Manzke von MARE Security hat uns
heute morgen auf einen derzeit aktuellen Exploit in der PCRE-Bibliothek
aufmerksam gemacht, der eine Remote Code Execution ermöglicht.

Kurzfassung: Die PCRE-Bibliothek kommt in großen Stil u.a. auf
Mailservern zur Spam-/Virenfilterung zum Einsatz, aber auch
Web-/Proxy-Server u.a. könnten Gebrauch davon machen. Updates der
Distributionen stehen noch aus, sollten aber umgehend eingespielt werden.

Ausführlicher Bericht mit Details dazu im Security-Bulletin von Markus
Manzke: https://8ack.de/bulletins/1433482265




--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin
--
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de
Heinlein Professional Linux Support GmbH

[hidden email]
https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
Reply | Threaded
Open this post in threaded view
|

Re: Lücke in PCRE-Bibliothek erlaubt Remote Code Execution

Florian Kaiser
> Unser Sicherheitsspezialist Markus Manzke von MARE Security hat uns
> heute morgen auf einen derzeit aktuellen Exploit in der PCRE-Bibliothek
> aufmerksam gemacht, der eine Remote Code Execution ermöglicht.

Vielen Dank für die Info in der Liste. Diese Lücke haben wohl viele übersehen,
da es kaum Publicity gab.

Was mich extrem stört ist, dass Distributionen für gravierende Lücken mit RCE
(die dazu noch ziemlich leicht fixbar sind) 4 Tage und mehr brauchen.  Debian,
Red Hat etc. sind seit mindestens 01.06 informiert und hatten inzwischen mehr
als genug Zeit, zu reagieren.

In letzter Zeit braucht es scheinbar immer erst eine Heise-Meldung (und
Reihenweise öffentliche PoCs bzw. Wild-Exploits), bis Ditributionen Fixes für
Sicherheitslücken wenigstens mittelfristig bereitstellen.

Ist ein echtes Ärgernis geworden.


Grüße
Florian


--
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de
Heinlein Professional Linux Support GmbH

[hidden email]
https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Senderadressen akzeptieren

Matthias Döring
Hi zusammen,

ich habe mal wieder das Problem mit einem 1&1 User zu kommunzieren >:o
Jetzt steht ja in Peers Buch Absender nicht direkt freigeben. Das macht
die Konfiguration mit greylisting und Blacklists zunichte.
Wie muss ich es jetzt konfigurieren damit mir dieser eine Absender seine
Nachrichten direkt schicken kann und meine Blacklists nicht die
Nachricht ablehnen?

smtpd_recipient_restrictions =
         permit_sasl_authenticated,
         permit_mynetworks,
         reject_unauth_destination,
         reject_rbl_client zen.spamhaus.org,
         reject_rbl_client dnsbl.sorbs.net,
         check_policy_service inet:127.0.0.1:10023,
         permit


--
Mit freundlichen Grüßen

Matthias Döring

--
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de
Heinlein Professional Linux Support GmbH

[hidden email]
https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
Reply | Threaded
Open this post in threaded view
|

Re: Lücke in PCRE-Bibliothek erlaubt Remote Code Execution

Ralf Hansen
In reply to this post by Florian Kaiser
Am 05.06.2015 um 10:24 schrieb Florian Kaiser:

>
>
> Was mich extrem stört ist, dass Distributionen für gravierende Lücken mit RCE
> (die dazu noch ziemlich leicht fixbar sind) 4 Tage und mehr brauchen.  Debian,
> Red Hat etc. sind seit mindestens 01.06 informiert und hatten inzwischen mehr
> als genug Zeit, zu reagieren.
>
> In letzter Zeit braucht es scheinbar immer erst eine Heise-Meldung (und
> Reihenweise öffentliche PoCs bzw. Wild-Exploits), bis Ditributionen Fixes für
> Sicherheitslücken wenigstens mittelfristig bereitstellen.
>
> Ist ein echtes Ärgernis geworden.
>
>
>
Hallo Florian,

es ist Dir doch freigestellt, Dich selbst als Maintainer z.B. für die
o.g. Pakete freiwillig zu melden.
Du forderst hier von der Community, dass Sie sich z.T. in ihrer Freizeit
sofort um diese Anliegen kümmern.
Dann nimm doch etwas Geld in die Hand und kaufe Dir SLES, dann hast Du
wenigstens einen Grund Dich dort zu beschweren.

--
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de
Heinlein Professional Linux Support GmbH

[hidden email]
https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
Reply | Threaded
Open this post in threaded view
|

Re: Lücke in PCRE-Bibliothek erlaubt Remote Code Execution

Max Grobecker
In reply to this post by Florian Kaiser
Hallo,


Am 05.06.2015 um 10:24 schrieb Florian Kaiser:
> Was mich extrem stört ist, dass Distributionen für gravierende Lücken mit RCE
> (die dazu noch ziemlich leicht fixbar sind) 4 Tage und mehr brauchen.  Debian,
> Red Hat etc. sind seit mindestens 01.06 informiert und hatten inzwischen mehr
> als genug Zeit, zu reagieren.

Für soooo furchtbar kritisch halte ich die Lücke für Postfix
(und die allermeisten anderen Anwendungen) eigentlich garnicht.


Zitat:
  "A remote or local user can create a specially crafted regular expression string that,
   when processed by the target application, will trigger a heap overflow in the PCRE
   library and execute arbitrary code on the target system."
http://www.securitytracker.com/id/1032453

Die Kernaussage ist "user can create a specially crafted regular expression string".
Es geht also um böse PCRE-Pattern, nicht um die Werte, gegen die das Pattern matchen soll.

Das würde bei Postfix AFAIK also nur zutreffen, wenn du fremde (unvertraute) Pattern für
Header- oder Body-Checks verwendest und dir jemand darüber dann seine eigenen Regulären Ausdrücke unterschieben kann.

Und meinetwegen auch bei SpamAssassin, wo es dann aber auch den expliziten Download entsprechend manipulierter
Regelwerke bedarf. So mit einer einfachen Mail mit bösem Inhalt sehe ich momentan keinen Weg, das auszunutzen.

Ich lasse mich da aber gerne eines Besseren belehren!


Viele Grüße aus dem Tal
Max



--
_______________________________________________
Postfixbuch-users -- http://www.postfixbuch.de
Heinlein Professional Linux Support GmbH

[hidden email]
https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users

signature.asc (836 bytes) Download Attachment