Das ist reichlich fahrlässig.
unterstellst Du damit,
dass Sicherheitslücken durch veraltete Compiler/Interpreter udgl. kommen
und nix mit etwaigem Pfusch im Quellcode zu tun haben?
ein if ( value = 7 ) doFunc( value ); wird durch einen neuen C-Compiler nicht besser
dass Sicherheitslücken durch veraltete Compiler/Interpreter udgl. kommen
und nix mit etwaigem Pfusch im Quellcode zu tun haben?
Teils. Lücken im Interpreter können sicheren Code unsicher machen und unsicheren Code noch unsicherer machen
Edit: Beispiel USN-4166-1
Summary:
PHP could be made to run programs if it received specially crafted network
traffic.
Software Description:
- php7.3: HTML-embedded scripting language interpreter
- php7.2: HTML-embedded scripting language interpreter
- php7.0: HTML-embedded scripting language interpreter
Details:
It was discovered that PHP incorrectly handled certain paths when being
used in FastCGI configurations. A remote attacker could possibly use this
issue to execute arbitrary code.Lukay Ja und Nein; Sicherheitsprobleme sollen behoben werden, ja klar; aber ich hab' Vorbehalte bei den ganzen Updatereien;
ich mein es ist ein ewiges Katz und Maus Spiel; am Beispiel von Browsern;
man stellt fest, dass ein Sicherheitsproblem in einer bestimmten Konstellation auftritt;
gut man hat das Problem gefunden, nur bei der Behebung alleine bleibt es meist ja nicht;
man erweitert den Browser mit Features - manche haben keine Relevanz was das HTML-Rendering angeht, manche aber schon;
und genau hier passiert es, manche Website Entwickler entdecken gefallen und nutzen diese; und jetzt rate mal:
das nächste Sicherheitsproblem wird entdeckt; mag es sein, dass es in Zshg. mit der Erweiterung steht, oder auch nicht;
soll heißen, dass Fortschritt/Entwicklung in diesen Bereichen eigentlich nur dieses Katz und Maus Spiel wiederspiegelt,
und mit tatsächlichen Fortschritt eigentlich nichts zu tun hat;
wenn ein Anti-Virus so richtig Hardcore Paranoia veranstaltet, dann würde er fast das ganze Web blockieren,
weil die Seiten, die beim CSS/HTML-Validator korrekt validieren sind rar; und alle anderen können Sicherheitsprobleme verursachen;
und bei PHP fängt der Fisch ja so richtig zu stinken an,
das merkte ich damals bei meinem Webmail - läuft zu Hause in einer VM - nachdem ich von PHP 5.3 auf 5.4 upgedated hatte:
mein Webmail lief nicht mehr ..., und dann wurde es so richtig zum Flickwerk;
weil es f. mein Webmail kein Update mehr vom Release meiner Distri her gab;
hatte mit dem Packet f. das nächste Release meiner Distri nachgeholfen und es wieder zum Laufen gebracht;
wenn ein Anti-Virus so richtig Hardcore Paranoia veranstaltet, dann würde er fast das ganze Web blockieren,
weil die Seiten, die beim CSS/HTML-Validator korrekt validieren sind rar; und alle anderen können Sicherheitsprobleme verursachen;
Wie viele Sicherheitslücken wurden eigentlich nur durch HTML & CSS ausgenutzt und wie viele mittels irgendwelcher JavaScript APIs? 
Letzteres hat mit validem Code soviel zu tun, wie eine Ölraffinerie mit Umweltschutz.
aber ich hab' Vorbehalte bei den ganzen Updatereien
Sicherheitsupdates klar, die müssen immer sein. Aber es kann leider nicht alles 20 Jahre lang in alte Versionen backported werden.
Irgendwann muss die Software nunmal geupdated werden
weil es f. mein Webmail kein Update mehr vom Release meiner Distri her gab
Davon würde ich sowieso weg gehen. Webapplications werden bei mir nur von deren offizieller Website runtergeladen und entweder von dort geupdated oder mit deren eigenem System. (z.B. owncloud bringt einen Self-updater mit).
Auf der Website der Software siehst du dann auch, welche abhängigkeiten bestehen. (php version, php extensions etc.)
Mit Webapplications hatte ich in dem Sinne noch nie Probleme.
Dank vhosts und php-fpm kann man ja auch problemlos verschiedene php Versionen parallel betreiben.
Wie viele Sicherheitslücken wurden eigentlich nur durch HTML & CSS ausgenutzt und wie viele mittels irgendwelcher JavaScript APIs?
das stimmt schon dass JavaScript hier nicht unproblematisch ist,
hier sollte man aber nicht verwechseln, wenn per JavaScript irgendwelche Malware hergeschleiert wird,
hat das mit Sicherheitslücken per se nichts zu tun; das ist by Design so vorgesehen;
einzig der Ausbruch aus der Sandbox, und nichtmal hier bin ich mir sicher, ob das nicht by Design so vorgesehen ist;
valider HTML/CSS Code ist in dem Zshg. eben nur selten zu finden;
schon klar, dass das nix miteinander zu tun hat, ist halt wie der sich an die StVO haltende Bankräuber;
Irgendwann muss die Software nunmal geupdated werden
klar, und damit werden so richtig die Bugs nach Hause geholt;
oder mit anderen Worten das Delta auf der Platte zwischen WinXP und Win7/8/8.1/10 ist
verglichen mit der Zunahme an Funktionalität Malware-Verdächtig
Neues Miniprojekt: Ausschnitte aus YouTube Videos in Endlosschleife abspielen:
https://serverless.industries/2020/08/28/loo…ube-videos.html
https://youloop.serverless.industries/#v=osxsfgWgqQY…=56.85&end=59.5
oder auch
https://youloop.serverless.industries/#v=osxsfgWgqQY…57.95&end=61.29
Wir hätten das Ding vor nem halben-dreiviertel Jahr gebraucht...
Da hat jemand mitgelesen...
Und, gibt es dazu noch Neuigkeiten? Die seltsamen Pakete trudeln nämlich nach wie vor ein:
67 2968 LOG_DROP all -- * * 10.0.0.0/8 0.0.0.0/0
37 1824 LOG_DROP all -- * * 192.168.0.0/16 0.0.0.0/0
24 1184 LOG_DROP all -- * * 172.16.0.0/12 0.0.0.0/0
12 504 LOG_DROP all -- * * 100.64.0.0/10 0.0.0.0/0
1 52 LOG_DROP all -- * * 169.254.0.0/16 0.0.0.0/0
73 PROTO=TCP DPT=445
13 PROTO=TCP DPT=23
10 PROTO=TCP DPT=443
10 PROTO=TCP DPT=2323
8 PROTO=TCP DPT=8080
5 PROTO=TCP DPT=5555
4 PROTO=TCP DPT=22
3 PROTO=TCP DPT=9527
3 PROTO=TCP DPT=3389
2 PROTO=TCP DPT=80
2 PROTO=TCP DPT=3306
2 PROTO=TCP DPT=1433
2 PROTO=TCP DPT=139
1 PROTO=UDP DPT=50761
1 PROTO=TCP DPT=50445
1 PROTO=TCP DPT=15612Das sieht nach Security Scans aus, vgl. z.B. für TCP/9527 https://isc.sans.edu/forums/diary/W…+9527TCP/25194/ . Die restlichen Ports sind entweder gut bekannt oder total unbekannt.
Und, gibt es dazu noch Neuigkeiten? Die seltsamen Pakete trudeln nämlich nach wie vor ein:
Code67 2968 LOG_DROP all -- * * 10.0.0.0/8 0.0.0.0/0 37 1824 LOG_DROP all -- * * 192.168.0.0/16 0.0.0.0/0 24 1184 LOG_DROP all -- * * 172.16.0.0/12 0.0.0.0/0 12 504 LOG_DROP all -- * * 100.64.0.0/10 0.0.0.0/0 1 52 LOG_DROP all -- * * 169.254.0.0/16 0.0.0.0/0 73 PROTO=TCP DPT=445 13 PROTO=TCP DPT=23 10 PROTO=TCP DPT=443 10 PROTO=TCP DPT=2323 8 PROTO=TCP DPT=8080 5 PROTO=TCP DPT=5555 4 PROTO=TCP DPT=22 3 PROTO=TCP DPT=9527 3 PROTO=TCP DPT=3389 2 PROTO=TCP DPT=80 2 PROTO=TCP DPT=3306 2 PROTO=TCP DPT=1433 2 PROTO=TCP DPT=139 1 PROTO=UDP DPT=50761 1 PROTO=TCP DPT=50445 1 PROTO=TCP DPT=15612
Nein, leider nicht. Ohne nachzuschauen bin ich mir auch recht sicher, dass diese Pakete nach wie vor auch bei mir noch ankommen. Da schau ich heute Abend mal danach.
Ich bin hier mal so frei und markiere mal den Support Mitarbeiter meines Vertrauens [netcup] Brian A. - vielleicht kann er ja Licht ins Dunkle bringen. 
Und ich klick auch noch drauf. 
Es hatte zum Glück kein Autoplay... (Chrome auf Android)
ich finde es ja mal toll, dass man zu Debugging-Zwecken was ausgeben lassen kann
... nsupdate -d -D -k ....
liefert das
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 43430
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 1
;; ZONE SECTION:
;myhost.domain.de. IN SOA
;; UPDATE SECTION:
myhost.domain.de. 0 ANY A
myhost.domain.de. 60 IN A 10.10.10.10
;; TSIG PSEUDOSECTION:
ddns-key. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1598724779 300 16 r1OMlasb2HD5ZHw== 43430 NOERROR 0
erification successful
show_message()
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id: 43430
;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;myhost.domain.de. IN SOA
;; TSIG PSEUDOSECTION:
ddns-key. 0 ANY TSIG hmac-md5.sig-alg.reg.int. 1598724779 300 16 uMj354uFpwF4LCw== 43430 NOERROR 0
done_update()
reset_system()
user_interaction()
get_next_command()
cleanup()
detach tsigkey x0x7e5a5f8
Shutting down task manager
shutdown_program()
Shutting down request manager
Destroy DST lib
Destroying request manager
Freeing the dispatchers
Shutting down dispatch manager
Destroying event
Shutting down socket manager
Shutting down timer manager
Destroying hash context
Destroying name state
Removing log context
Destroying memory context... nsupdate -k ...
aber das
update failed: NOTAUTHnebenbei auch wenn es oben so aussieht, dass es fehlerfrei war, das war es nicht;
wie finde ich jetzt heraus wo der Pferdefuß ist?
cat <<EOF |nsupdate -k /etc/ddns.key
server myip
local myip
zone myhost.domain.de
update delete myhost.domain.de. A
update add myhost.domain.de. 60 A 10.10.10.10
send
EOFwelche Optionen habe ich noch da zu suchen;
angemerkt sei: das läuft auf dem selben Host auf dem auch der DNS (BIND) läuft;
Hat hier noch jemand Probleme über A1 (Österreich)? Egal ob DSL oder Mobilfunk, bestimmte AS sind nicht mehr oder nur mit extrem hohem Packet Loss erreichbar. Das dürfte seit ca. 12 Uhr so sein. Betroffen sind u.a. twitter.com (letzter Hop lg2-1171.as8447.a1.net), opendns.com (letzter Hop ae-3.r20.vienat02.at.bb.gin.ntt.net), …
Hat ein paar Ähnlichkeiten mit dem Problem von vor einem Monat. Nur mit dem Unterschied, dass es dieses Mal auch das Mobilfunknetz betrifft und der AON-Proxy ebenfalls die gleichen Symptome zeigt.
Edit: Je mehr ich das analysiere, desto eher habe ich das Gefühl, dass es nicht nur A1 betrifft. Das ist eventuell ein Problem außerhalb deren Einflussbereichs.
Benutzt hier jemand Cloudflare? Die haben auch Probleme: https://www.cloudflarestatus.com/
Bei Centurylink (ehemal Level 3) gibt es derzeit scheinbar massive BGP-Probleme.
https://twitter.com/CenturyLink/status/1300063983739772928
Viele Infos scheint es nicht zu geben, ich habe es hier bemerkt: https://status.atlantic.net/
AWS scheint auch Probleme zu haben: https://status.aws.amazon.com/
Network Connectivity
We are observing an issue with an external network that is preventing some customers from reaching AWS Regions. Connectivity within our regions as well as connectivity from other networks is not impacted.
Es scheint hier einiges aktuell betroffen zu sein. Cisco Duo meldete vorhin auch bereits Ausfälle, aufgrund eines großen ISPs.