CVE-2017-7494 - Remote code execution from a writable share

Bug

( Salcay v | 2017. 05. 24., sze – 20:47 )

Úgy hangzik, mintha a potenciálisan libwannacry.so potenciális belépési pontját találták volna meg...

--
Where do you want to go today?
[nobody@salcay:~]$_

( b | 2017. 05. 25., cs – 13:52 )

Ki kell vágni mint egy tumort és jól el kell felejteni az egész sambát.
Nem tudom miért kell eröltetni ezt az m$ fost.

--
GPLv3-as hozzászólás.

Mert van rá igény és ez az alapja a linuxos Active Directory szervernek is. Enélkül a projekt nélkül még ennyi felhasználója se lenne a különböző disztribúcióknak, mint most. Amúgy meg nem az MS írta, csak az MS protokolját támogatja. Az OpenSSL-ben is voltak/vannak érdekes bugok.

Ez egy kalap. Nem is, mert elefánt, csak megette a kígyó!
A találatok esetleg user és group managementre jók, többre nem nagyon. GPO terjesztés, Kerberos integráció, és egyebek? Tudom, fel lehet rakni és beállítani kézzel, de ugyanez bármelyik bögrémre is igaz.

--
Where do you want to go today?
[nobody@salcay:~]$_

Hát, ha már jött válasz a kérdésre, én bizony rákattintottam, érdekelt a téma.

Első találat a linkre: 8 Alternatives to Microsoft Active Directory | Top Best Alternatives

Nézzük csak:

  • 1. Microsoft Active Directory: Hát, ez önmaga, nem is értem, hogy nem jutott eszembe, mint alternatíva... Viszont kell neki a Windowsos fájlmegosztás, meg úgy az egész AD, szóval ide nem lesz jó nekünk...
  • 2. Univention Corporate Server: Sambát használ, szóval nem oldja meg a problémánkat.
  • 3. LepideAuditor for Active Directory: Ez egy auditor program az AD felügyeletére, kezelésére, és mellesleg a Windows fájlmegosztást is auditálja. Nem is értem, miért alternatíva ez, kell hozzá egy AD.
  • 4. OpenLDAP: Ez nem igazán az AD alternatívája (illetve csak egy része), de legalább a sambaval, kerberossal, binddel összekövtve már majdnem egy teljes AD-t tud helyettesíteni. Így kell összekötni sambaval.
  • 5. JXPlorer: Ez egy LDAP browser, java-ban írva. Nem világos, hogy miért vették egyáltalán ide. Tényleg valami hasonlót tud, mint az AD grafikus felülete, de ez nem egy alternatíva.
  • 6. 389 Directory Server: Ez egy LDAP szerver, ha fájlokat hálózati megosztást is szeretnénk mellé, akkor máris hozzá lehet csapni a samba-t is.
  • 7. ApacheDS: Ez egy JAVA-ban írt LDAP szerver + kerberos szerver, alapvetően mindent tud, amit egy Windows AD is adna, leszámítva a fájlmegosztást. Ha azt is szeretnénk, akkor sincs gond, a Samba-val is együtt tud működni.
  • 8. Samba:Remek alternatíva, csak nagyon kell hozzá a SAMBA!

Tulajdonképpen el lett ismerve, hogy nincs másik alternatíva. Vagy MS AD-t használok, vagy samba-t valamivel.

Nagy Péter

Úgy emlékszem régi olvasmányaim alapján, hogy az Active Directory az valamilyen Novell terméken alapult (nem tudom, hogy csak az ötletén vagy a megvalósításon). Azóta, amióta ezt olvastam, elég sok víz lefolyt a Dunán és mivel egyik terméket sem használom, nem tudom, hogy milyen változások történtek azóta.

A kérdésem kb. annyi, hogy vajon a Novell termék (ha még egyáltalán létezik), ki tudná váltani az Active Directory-t, vagy nem?

Ha jól sejtem, akkor az AD az voltaképp csak az adatokat tárolja, mint mondjuk egy LDAP szerver, és az a nagy jósága, hogy 1) az adatok struktúrája ismert és jól definiált, 2) egy csomó rendszer ismeri és integrálódik vele.

Vagy van valami más is, amit tud?

Nem alapult az semmilyen Novell terméken, az akkor NDS (aztán eDirectory) konkurenciája volt.

"Mint mondjuk egy LDAP szerver", igen, pont annyira tér el ez a "jól definiált" struktúra az addigi LDAP szerverekétől, hogy semmi mással nem tudod kiváltani. Nem véletlenül nem lehet OpenLDAP szervert Samba 4 AD backendként sem használni (pedig megpróbálták).

Az AD egy tipikus példája annak, hogy lehet nyílt szabványok felhasználásával egy olyan terméket csinálni, aminek aztán egy nyílt szabványú helyettesítője sem lehetséges.

"Mint mondjuk egy LDAP szerver", igen, pont annyira tér el ez a "jól definiált" struktúra az addigi LDAP szerverekétől, hogy semmi mással nem tudod kiváltani. Nem véletlenül nem lehet OpenLDAP szervert Samba 4 AD backendként sem használni (pedig megpróbálták).

Időnként még próbálják fel-fel támasztani (azt hiszem Andrew Tridgelll fejtegette valahol, hogy az OpenLDAP replikációja mennyivel jobb, mint az AD-s), de tényleg nem túl nagy prioval. Egyébként eredetileg az volt a gond, hogy itt-ott nem a standard LDAP működést várja az AD (tranzakciókezelés környékén volt a legtöbb gond), bele lehetne patchelni, csak most már a Samba-ból lesz nehéz kihúzni (ugyanúgy, mint a Heimdal kerberos-t, elvileg 4.7-re végeznek vele a piros kalaposok és lehet MIT krb-vel használni - és azt ígérik, hogy a kövi point release RHEL-ben tech preview-ként ott lesz az AD Samba).

Az AD egy tipikus példája annak, hogy lehet nyílt szabványok felhasználásával egy olyan terméket csinálni, aminek aztán egy nyílt szabványú helyettesítője sem lehetséges.

Na ja, minden csak kicsit nem kompatibilis a standarddal, meg mindent csak kicsit egészítenek ki :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

pont annyira tér el ez a "jól definiált" struktúra az addigi LDAP szerverekétől, hogy semmi mással nem tudod kiváltani. Nem véletlenül nem lehet OpenLDAP szervert Samba 4 AD backendként sem használni

Ez érdekes.

Le tudod írni röviden, hogy mi hiányzik mondjuk az OpenLDAP-ból, ami miatt nem jó backendnek?

Itt részletesen is találsz dolgokat: https://wiki.samba.org/index.php/Samba4/LDAP_Backend
Itt meg a legutolsó status update-t, amivel találkoztam az OpenLDAP back-endről ill. hogyan tervezték/tervezik (nem tudom, foglalkoznak-e még vele) az összekötést: https://sambaxp.org/archive_data/SambaXP2014-DATA/thu/track1/Nadezhd_Iv…

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem az a baj, hogy hiányzik belőle valami, hanem az, hogy az alapvető sémában is vannak különbségek.

http://ldapcon.org/2015/wp-content/uploads/2015/09/ivanova-samba_backen…


Conflicts with standard LDAPv3
– Same attribute name, different OID
– Object classes with changed definitions, attributes that in AD are operational

Meg még jópár dolog.

a windózt a wanacry miatt (meg egyéb vírusok, meg telemetria, meg hirdetések, meg privacy, meg kémkedés, etc,etc,etc miatt) a sambát meg topic indító cikk miatt kell kiváltani.
11 évvel ezelőtt kellett használnom ilyen windózos baromságot azóta nem hál istennek. Mindent ki lehet és kell váltani szabad szoftverrel.

--
GPLv3-as hozzászólás.

"Novell terméken alapult" -- nem. "Exchange Server was an entirely new X.400-based client–server mail system with a single database store that also supported X.500 directory services. The directory used by Exchange Server eventually became Microsoft's Active Directory service, an LDAP-compliant directory service which was integrated into Windows 2000 as the foundation of Windows Server domains."

"akkor az AD az voltaképp csak az adatokat tárolja, mint mondjuk egy LDAP szerver" -- nem. Az AD egy LDAP szerver és még egyebek is tartoznak oda.

Üdv,
Marci

( uid_3194 | 2017. 05. 28., v – 19:47 )

Kipróbáltam a javasolt

nt pipe support = no

beállítást több működő samba szerveren is, oszt onnantól fogva XP és Win7 kliens nem tud csatlakozni hozzá (ez a kettő volt kéznél), szóval hatásos :)