Kritisk säkerhetsuppdatering för OS X

Hyggligt gjort av David!

Är det samma variant som ni kör på 99macs servrar?

Dendär uppdaterades ju för några dagar sedan (2/12) via systemuppdateringen, men kan vid moddade Apache-servrar missa.
(Min var så lite moddad så den uppdaterades, kollade med pico /etc/httpd/httpd.conf )
Kolla i /var/log/install.log om uppdateringen tog.
Jag sökte lite info i onsdags och då fanns det inget känt som använde hålet - men det gäller ju att få stopp innan sådant kommer
(Mer info < http://www1.netsec.net/content/news/pr/2004/2004-12-06.jsp >)

Kolla infon så blir måhända chocken mindre allvarlig (så att säga)

edit:
Mer info < http://thewhir.com/marketwatch/app120904.cfm >
< http://www.techworld.com/security/news/index.cfm?NewsID=2770&Page=1&pagePos=2 >
Hittar inte dendär braiga länken jag strosade runt på, men…

nej, men det går ju att göra manuellt också

Någon vänlig själv kan väl upplysa Macnytt om att de lider av samma problem.

/M

Tja, du kanske kan göra det?

någon vänlig skäl på macnytt tipsade här.. http://macnytt.se/forum/index.lasso?forum_part=posts.inc&a=readposts&headtopic=1&undertopic=14150

Jag tror nog de visste det innan er. Det var ju Macnytt som tipsade er ju.

Nja, jag kunde se deras SQL-lösen långt efter att 99mac hade stängt igen säkerhetsluckan.

/M

Dessutom är det dålig säkerhetspolicy att ha configfiler (även om det är php-kod) i en publikt läsbar mapp. Det är god praxis att alltid ha dessa utanför htdocs (eller annat directory som är mappat).

Jag kör förvisso GNU/Linux på min server men jag undrar ändå då mina configs ligger i en mapp som jag tror är publik. Vad menar du med publik/inte publik? och kan jag includea saker som inte ligger i web-trädet? Varför är det så dumt att ha configfiler iform av php-kod om de slutar på .php och inte skriver ut något?

Du får gärna förklara för mig varför detta är dumt. För de är ju självklart inte öppet läsliga.

Ja, du kan inkludera det som ligger utanför webbrooten. Och det är det som alltså är "ej publikt". Ett include-kommando i PHP använder alltid filsystemets sökvägar så om du skriver include("../hemligmapp/config.txt"); i en fil som ligger i din webbroot så kommer den att leta efter en fil som ligger utanför webbrooten.

Därför den dagen när PHP-filen inte skickas genom PHP-parsern så skickas den som klartext istället. Det är precis det som det här säkerhetshålet handlar om. På grund av en bugg (eller inte en bugg egentligen utan snarare ej genomtänkt implementering i förhållande till HFS+) så kunde man få läsa PHP-filer i klartext.

Alltså, ta det lugnt nu. Så total-kritiskt är det inte.

Det finns inga kända exploits och hålet patchades när det upptäcktes. Det är annat än vad man kan säga om våra vänner som kör Windows.

Ciryon

Jag fattar inte ett jota av vad ni snackar om.
Kan någon förklara.

Aha, det är om man har en server. Ja dåsa att ju va lugna gatan för mig.
Skönt att inte vara så insatt datoranvändare. Slipper förhoppningsvis få inblick i den mörka världen ett tag till.

Risken finns om man har en webserver som använder mer än cgi-bin för scripning och där man förvarar viktiga saker i resursdelar till filerna (samt för enkelhets skull, har en standardliknande installation så att man hittar filerna manuellt) - samt sist och inte minst, inte har uppdaterat enligt 2/12 eller om den uppdateringen av httpd.config inte tog…

Inte totalkritiskt?

Det hänger på hur duktig man var när man installerade sina tjänster.

Om 99mac hade använt "fel" lösenord för att ansluta till MySQL hade jag kunna se det och använda det för elaka syften. Om 99mac hade haft MySQL-portarna öppna, och ett MySQL konto som tillåter anslutningar utifrån "%" eller om jag på annat sätt kunnat exekvera .php filer lokalt på burken hade jag kunnat kopiera och radera hela 99mac.

Jag har som exempel Andreas Lejion:s adminlösenord eftersom det står öppet i config filerna i MacWorlds forum (som också använder OS X/PHP/MySQL). Jag har förgäves försökt nå honom för att be dom uppdatera sin server.

Undrar hur många som får sina burkar hackade i helgen.

Hmm... gäller det där också om man kör vanliga OS X som webbserver?

Ganska många om där du... :rolleyes:

Apple web hole still open

http://www.techworld.com/security/news/index.cfm?NewsID=2770

Är det bara jag eller är det så att man får patcharna mycket tidigare om man kör på opensource os (linux, openbsd, freebsd osv)? Kör inga skarpa databaser under Mac OS X så jag tar denna nyhet med ro, min utvecklings burk kör naturligt vis OS X men den ligger i väskan nu utan nät så det är relativt lungt här...

[Edit] iofs så finns inte .ds_store någon annan stans än hos os x... [/Edit]

Har ingenting att jämföra med men det verkar ofta som om Apple väntar tills de samlat ihop ett gäng uppdateringar och sedan släpper dessa i en uppdatering. Har inga belägg men visst känns det så.

jo men det är ju upp till 4D att patcha webstar.. Det är en funktion av HFS+ inte en bugg.. 4D har inte tagit hänsyn till detta så dom får väl patcha sina programvaror..

Och detta har de gjort nu. http://www.versiontracker.com/dyn/moreinfo/macosx/11438

Ciryon

Måste nog hålla med caben, tar inte många minuter att hitta Leijons sql lösen...

Helt överraskande var det ju inte om man hade läst detaljerna i senaste säkerhetsuppdateringen (vilket jag berömde Apple för att de skriver ut, när det gäller just den aktuella uppdateringen).

Här är en tillfällig lösning för alla som kör 4D WebSTAR istället för Apache:

Workaround for Potential Security Vulnerability on HFS+ Volumes
This Admin Modify Rule will provide a workaround to block any potential vulnerability in HFS+ volumes that would allow an attacker to access a files data fork or return the file listings from a web server running on Mac OS X. Thanks to Fletcher Sandbeck of Blue World for creating this rule.
Open the 4D WebSTAR Admin Client and access DefaultSite.
Open the Web Rewrite > Admin Modify Rules section.
Create a new rule with the following properties:

URL ends with "data" OR
URL ends with "rsrc" OR
URL contains ".ds_store"
Change root path to ""
Change URL path to "/"
Continue with Rule "stop"

Move the rule so it is first in the list and check the "Preprocess" checkbox. Click "Save" to save the rule. This Admin Modify Rule should apply globally and protect every site on the WebSTAR server.

Detaljerad info har de ju haft sedan 2001 när de släppte 10.1 . Gäller bara att ha tillgång till informationen. Typ:[email protected]

Jo men visst kan man lägga htdocs på UFS men hur många gör detta? Läste om detta 2001 men trodde faktiskt att Apples apache patchar lirade...