PHP Vulnerability-Fix heute 16 Uhr

[Ralph]

Wo genau im Panel müssen diese Direktiven eingestellt werden? Es liest sich so, als ob das als zentrale Einstellung empfohlen würde?

Edit client > PHP > Additional PHP directives > Non-overwritable directives

Code: Select all

session.upload_progress.enabled=0

[goldene-zeiten]

Code: Select all

for dir in /opt/keyhelp/php/*/etc/conf.d; do
    [ -d "$dir" ] || continue
    printf 'session.upload_progress.enabled = Off\n' \
        > "$dir/99-disable-upload-progress.ini"
done

Ja, kommt im Grunde auf das gleiche Resultat raus, halt außerhalb der KH *.conf ... es wird so beim speichern nicht überschrieben, ob es greift müsstest mal in die info.php schauen, und später ggf. wieder mauell löschen.

Und wie hätte deine Lösung ausgesehen? Wo hätte man die Direktiven da hinterlegen müssen?

[Ralph]

@Alexander

Alex, was meinst Du dazu ... ?
viewtopic.php?p=59982#p59982
gesetzt ist im Panel z.b.

Code: Select all

session.upload_progress.enabled = off
oder
session.upload_progress.enabled = 0

daraus wird dann in der userphp*.conf

Code: Select all

php_admin_value[session.upload_progress.enabled] =
php_admin_value[allow_url_fopen] =

also alles mit off oder 0 und einem Leerzeichen dazwischen, endet so

Im info.php wirds es dann allerdings als off angezeigt:

[omexlu]

Du machst zuviel in die Hose, schau dir an unter welchen Umständen das progress-enabled überhaupt Stress machen kann.

[Ralph]

Du machst zuviel in die Hose, schau dir an unter welchen Umständen das progress-enabled überhaupt Stress machen kann.

Es geht ja bei dieser Sache nicht generell um "session.upload_progress.enabled" ... würde ja auch ggf. andere Settings, die off oder 0 gesetzt sind, betreffen.

[Alexander]

Es wird doch korrekt interpretiert als "Off".
Ob es in der Konfiguration nun so:

Code: Select all

php_admin_value[session.upload_progress.enabled] =

oder so:

Code: Select all

php_admin_value[session.upload_progress.enabled] = off

steht, ist doch nur ein kosmetisches Problem, solange es korrekt ausgewertet wird.

[Tobi]

Ja klar, das draußen lauern noch Exploits. Gefährliche sogar! Soll ich mich jetzt deswegen verrückt machen? Hmm ist auch ein Plan. Der endet aber zwangsläufig immer mit „sudo shutdown -Hn“. Weil woher soll ich denn wissen welche Lücke, die ich noch nicht mal kenne, als nächstes ausgenutzt wird?

Sollte ich an einen echten Profi-Hacker geraten sein, auch dann hilft nix mehr. Weil wenn der schlauer ist als ich bemerke ich dessen Anwesenheit gar nicht erst und die o.g. Anpassungen bleiben wirkungslos weil mein gesamtes System schon komprimiert ist.

Anscheinend sind da draußen tatsächlich noch weit über 50% aller Systeme verwundbar und Angriffen mit phpShell hilflos ausgeliefert. Die sind das wahre lohnende Angriffsziel.
Warum soll ich mir also Stress machen?

Tatsächlich stelle ich auf _allen_ Servern weniger Bot-Traffic fest seitdem alle Patches eingespielt sind. Wer sein OS up2date hat und nur die gepatchen PHP Versionen seinen Kunden bereit stellt, hat aktuell gar nichts zu befürchten.

[Ralph]

Es wird doch korrekt interpretiert als "Off".
Ob es in der Konfiguration nun so:

Code: Select all

php_admin_value[session.upload_progress.enabled] =

oder so:

Code: Select all

php_admin_value[session.upload_progress.enabled] = off

steht, ist doch nur ein kosmetisches Problem, solange es korrekt ausgewertet wird.

Danke, die Frage war nicht dumm oder nervig gedacht

[hase]

Update:

- PHP 8.1 Pakete sind mitlerweile auch live.

- Tests mit PHP 5.6 + Patch laufen

Hi,
gibt es schon einen aktuallisierten Stand bzgl. PHP 5.6 Patch?

[mhagge]

Wenn ich mir viewtopic.php?t=14660 so anschaue, würde ich vermuten / unterstellen, dass es momentan was Wichtigeres gibt.

[hase]

Sorry das ich nachgefragt habe

[Tobi]

Wo genau liegt denn das Problem?

Die meisten 5.6er Installationen scheitern bei neueren PHP Versionen lediglich an den entfernten Funktionen.
Dafür gibt es aber Wrapper-Klassen welche die fehlenden Funktionen nachbilden und den Code fit für 7.X machen.

Ich habe auch die letzten Tage damit verbracht irgendwelche uralten Typo3 Installationen zumindest fit für 7.4 zu machen.
Alle Fehler konnte ich in den Domainlogs einsehen und beheben.

Ich denke da bin ich nun wesentlich robuster aufgestellt und die Arbeit hat sich definitiv gelohnt.