News AMD SEV: Manipulation der Spannung ermöglicht Angriff auf Epyc

[xexex]

Gerade im eigenen Netz wirst du alles aufschlüsseln wollen, vor allem auch wegen Malware.

Wenn man sowas macht, dann bricht man die Verschlüsselung den dem Server auf, an dem man die Pakete überprüft und verschickt keine unverschlüsselten Pakete über das Netzwerk.

der Verkehr intern im RZ zwischen Load-Balancer und Server(n) wird aber in der Regel aufgeschlüsselt.

Wüsste keinen sinnvollen Anwendungsfall, wieso man es so handhaben sollte, schon gar nicht wenn es an dieser Stelle um sicherheitskritische Daten geht. Entweder ist mir die Sicherheit egal, dann brauchen wir auch nicht über SEV zu diskutieren oder ich habe auf dem Server wichtige Daten und dann lasse ich in dem "Haus" keine Fenster offen.

Ergänzung (13. August 2021)

Und nein, diese Techniken wurden vor allem entwickelt, um den RAM-Inhalt zu verschlüsseln,

Die von mir genannten Techniken haben die primäre Aufgabe VMs vor unerlaubten Zugriff zu schützen. RAM Verschlüsselung ist nur eine Teilkomponente davon.

https://docs.microsoft.com/en-us/wi...c-shielded-vm/guarded-fabric-and-shielded-vms

https://developer.amd.com/sev/

Um eine VM vor einer anderen zu schützen, braucht es diese Technologie nicht.

 

[.Sentinel.]

Multi-Vektor Angriff hört sich mit Verlaub arg konstruiert an,.

So funktionieren heutzutage 99% der erfolgreichen und effektiven Angriffe.
Erstmal schaust Du, dass Du Informationen über das Ziel sammelst. Gehst in Korrespondenz mit denen.
Dann erfährst Du schonmal was über die Kommunikationsgepflogenheiten und den Strukturen nach außen.

Dann schleust Du mit oben erworbenem Wissen einen primitven Loader ein (social hacking), der die Grundgegebenheiten auf dem System checkt und passende Malware nachlädt (daher Multivektor).

Die checkt dann wiederum die kritischen Systeme ab (DNS, DHCP, Gateways) usw. und prüft, ob da z.B. ein veraltetes SMB (alte Storages und Scanner können oftmals nur damit) oder RDP zum Einsatz kommt. Wenn ja, dann bist Du bereits so gut wie auf dem Server. Und das am Endpoint, also unverschlüsselt.

Dann mit dem Datenabgreifen nicht übertreiben (Thresholds niedrig halten), damit das ganze nicht auffällt á la "meine Maschine/Netzwerk/Internet ist plötzlich so langsam"...

Ich kann mir allerdings gut vorstellen das Spectre und Co Null nachverfolgbar sind, also ja das ist vllt lahm und du greifst nur Zufallsdaten ab aber dafür wirst du nie entdeckt und was da über die Zeit rumkommt mag dann doch interessant sein.

Siehe oben. Zudem ist Hacking keine Spielerei.
Da geht es um haufenweise Geld. Kein Mensch bedient sich da ineffektiver und kaum erfolgsversprechender Methoden.

 

[cloudman]

@.Sentinel. du schon recht was die Angriffsvektoren angeht. Hier geht es ab vor allem darum die Server vor internen Zugriffen zu schützen. Gerade in großen Rechenzentren wo du nicht jeden admin beim Mittagessen triffst oder eben in der Cloud. Wer so etwas wie shielded VMs und ähnliches betreibt hat in der Regel keine Scanner oder antike SMB Protokolle im Einsatz. Bei Amazon oder MS in ihren Rechenzentren sicherlich nicht. Die Cloud Anbieter sind auch die bei denen diese Technologie am häufigsten zum Einsatz kommt. Siehe z.B.
https://docs.microsoft.com/en-us/wi...hat-is-shielding-data-and-why-is-it-necessary

 

[.Sentinel.]

@.Sentinel. du schon recht was die Angriffsvektoren angeht. Hier geht es ab vor allem darum die Server vor internen Zugriffen zu schützen. Gerade in großen Rechenzentren wo du nicht jeden admin beim Mittagessen triffst oder eben in der Cloud. Wer so etwas wie shielded VMs und ähnliches betreibt hat in der Regel keine Scanner oder antike SMB Protokolle im Einsatz. Bei Amazon oder MS in ihren Rechenzentren sicherlich nicht. Die Cloud Anbieter sind auch die bei denen diese Technologie am häufigsten zum Einsatz kommt. Siehe z.B.
https://docs.microsoft.com/en-us/wi...hat-is-shielding-data-and-why-is-it-necessary

Die Rechenzentren, in welchen Daten lagern, bei denen es um wirklich was geht, sind doch sowieso nochmal ganz anders abgesichert. Alleine den Server zu finden, auf dem man Daten abgreifen wollte ist extrem aufwändig.

Dann sind die Racks selbst inzwischen zugangsgesichert, so dass ein einzelner Admin da garnicht mehr rankommen kann. Da brauchste dann ne zweite Person mit Zusatztoken um das Ding überhaupt auf zu kriegen.
Telefonische Meldepflicht beim betreten des Rechenzentrums, Fingerprintscanner für die primären Zugangsschranken. Kameraüberwachung auf Schritt- und- Tritt.

Eine Quernutzung der VMs ist dort außerdem ausgeschlossen. Kritische Systeme bleiben abgeschottet unter sich.

Wer sollte sich das antun, auf diesem Weg irgendwelche Daten abgreifen zu wollen.....?
Im konkreten Fall- Downtimes werden minutiös protokolliert. Physikalische Kommunikationsports an den Servern sind gesperrt. Das möcht ich sehen, wie da einer ohne Überwachung einfach die Spannungen manipuliert, ohne Notwendigkeit das Chassis öffnet oder ins passwortgeschützte Bios geht usw. usf.

 

[cloudman]

@.Sentinel. Sehe ich ähnlich wie du. Panisch muss man deswegen nicht werden. Da muss schon viel zusammen kommen das man damit in der Praxis Erfolg hat bzw. so aufwendige Angriffe überhaupt in Betracht zieht.
Ist wahrscheinlich marketing technisch schlimmer als es wirklich ist.
Gerade wenn Leute darüber diskutieren die die technischen Hintergründe nicht so ganz verstehen..

 

[Atkatla]

Die Lücken bei Intel haben es erlaubt Daten aus anderen VMs abzuschnorcheln wenn du Zugriff auf irgendeine VM auf einem Server hattest.

Für den Angreifer, der gezielt Daten abschnorcheln möchte, ist die Methode aber dennoch untauglich. Denn es ist nicht vorhersehbar, welche andere VM und welche Speicherbereiche gerade auf dem Partner-Kern sind. ( https://www.computerbase.de/2018-08/openbsd-hyper-threading-smt-intel-security/ ). Zumal die VMs in den Clustern und auf den Hypervisoren auch noch dynamisch unterwegs sind.

Whatever, die Lücke bei amd ist nur halb so wild wie die bei Intel (und wie wild die wirklich war kann und will ich gar nicht beurteilen, der Fakt das Open BSD damals Smt hart deaktiviert hat reicht mir hin um das als nicht ganz banal einzustufen).

Die Entscheidung von OpenBSD kann man eigentlich fast Richtung PR einstufen, um sich als besonders sicherheitsbewusst darzustellen, da man dieses Angriffsszenario mit anderen, einfachen Methoden migitieren kann z.B. den Hypervisor anweist, die zwei logischen Kerne eines physischen Kerns immer nur den virtuellen Kernen einer VM zuzuweisen (die meisten VMs haben ja zwei virtuelle Kerne oder mehr). Wenn OpenBSD dazu nicht in der Lage ist... deren Problem. Zusätzlich lässt sich das Problem auch organisatorisch migitieren, indem man VMs unterschiedlicher kritischer Kunden nicht auf den gleichen Hosts laufen lässt.

Daher ist die AMD-Lücke eben nicht "halb so wild". Beide Angriffe spielen in der gleichen (in der Praxis unbedeutsamen) Arena und wären in der Praxis im Vergleich zu regulären, herkömmlichen Angriffen kaum ertragreich und für den Angreifer bzgl. der Ausbeute völlig unvorhersehbar. Wenn man nicht mit unterschiedlichem Maß misst, sind entweder beide gleich schlimm oder gleich unbedeutend.

 

[GrumpyCat]

Beide Angriffe spielen in der gleichen (in der Praxis unbedeutsamen) Arena

Hm:
"It then leaks hypervisor memory from attacker-chosen addresses by executing the eBPF interpreter in hypervisor memory as a Spectre gadget using indirect branch
poisoning (aka branch target injection), targeting the primary prediction mechanism for indirect branches. We are able to
leak 1809 B/s with 1.7% of bytes wrong/unreadable."
https://spectreattack.com/spectre.pdf

Ein paar KBytes/Sekunde von frei wählbaren Adressen ist schon nicht ohne, oder?

Und wenn viele VMs auf einem Host laufen, mag's länger dauern, aber was macht das schon?

 

[mae]

Vor "kriminellen Administratoren" kann man sich nicht wirklich schützen...

Wenn man Zugriff auf die Maschine hat sind die Daten nicht mehr vertraulich. Einzige was zu 99,9% schützt ist komplette Verschlüsselung.

Das ist das Versprechen von SEV, dass alles verschluesselt ist, damit auch ein krimineller Administrator (oder auch ein Administrator, der gesetzesgemaess einem Geheimdienst den Zugriff gewaehren muss) nicht auf die in der Cloud liegenden Daten zugreifen kann.

Ich kann mir schon vorstellen, dass AMD diese Luecke schliessen kann, aber was ist dann mit den EPYCs mit dieser Luecke? Alle aus der Cloud herausschmeissen und an die Leute verkaufen, die ihren Admins vertrauen?

 

[cirrussc]

Rumspielen an der Versorgungsspannung wird schon lange genutzt um lesegeschützte µc auszulesen.

Das ist mir bisher tatsächlich entgangen. Wo findet man da genaueres?

 

[Atkatla]

Ein paar KBytes/Sekunde von frei wählbaren Adressen ist schon nicht ohne, oder? Und wenn viele VMs auf einem Host laufen, mag's länger dauern, aber was macht das schon?

Sehr viel macht das, (selbst wenn wir annehmen, dass die Serverbetreiber die entsprechenden Gegenmaßnahmen nicht ergriffen haben was im professionellen Umfeld eher nicht zu erwarten ist): weil zum einen weil VMs auch zwischen Hosts wechseln (DRS & Co) und der Angreifer zwar die Adresse wählen kann, aber der Kontext fehlt, in welchen er dann die mit zwei Kbyte pro Sekunde erlangten Speicherinhalte stellen kann. Zusätzlich stellt sich für ihn die Frage, wo (anwelchen Adressen) er denn nun auslesen müsste. Die Speicherbereiche sind im Vergleich dazu riesig. Und hast du eine Vorstellung, wie schnell sich die Speicherinhalte ändern? Da kannst du mit 2 kbyte/s gar nichts anfangen, selbst wenn du auch nur ungefähr wüsstest, wo du schauen müsstet.
Z.B. ich will irgendwo eine bestimmte Information auslesen, dann müsste ich ja wissen, auf welche physische Speicheradressen der Hypervisor die VM und dann darin die gesuchte logische Speicheradresse darin gepackt hat, sofern man die überhaupt weiss. Das sind drei Variablen, die du als Angreifer in dem Moment nicht weisst. Und alles auszulesen geht angesichts der Größe und der Dynamik nicht.

In der Praxis musst du schauen, welche Angriffsmöglichkeiten nach den Microcode-Updates und den Gegenmaßnahmen der OSse, Hypervioren & Co überhaupt noch übrigbleiben. Wenn man den Aufwand, Möglichkeiten und Nutzen der verbleibenen Angriffsvektoren gegenüberstellt, sind die herkömmlichen Angriffsvarianten um ganze Größenordnungen erfolg- und ertragreicher.

Die meisten überschätzen diese Angriffsvektoren und richten sich nach dem, was am Anfang so auf den Newsseiten so publiziert wird. Mit den darauf folgenden Gegenmaßnahmen auf den einzelnen Ebenen beschäftigt sich dagegen keiner, weswegen es zu falschen Vorstellungen darüber kommt, wie und wo nun noch welche Lücke in welcher Form ausnutzbar sei. Wer liest denn z.B. schon sowas hier, wenn er damit nicht direkt zu tun hat? https://kb.vmware.com/s/article/52245
In der Folge werden am Stammtisch dann die alten Interpretationen weitererzählt und falsch eingeschätzt, obwohl die Welt schon längst weiter ist.

 

[GrumpyCat]

weil zum einen weil VMs auch zwischen Hosts wechseln (DRS & Co) und der Angreifer zwar die Adresse wählen kann, aber der Kontext fehlt, in welchen er dann die mit zwei Kbyte pro Sekunde erlangten Speicherinhalte stellen kann.

Die Hoster, die ich kenne, migrieren VMs nicht ungefragt zwischen Hosts, von Billigstangeboten oder Serverless-Unsinn abgesehen.

Und im Paper steht insbesondere, dass man auch Hypervisor-Speicher auslesen kann. Da hat man dann allen Kontext, den man sich wünschen kann.

Ohne entsprechende Gegenmaßnahmen stehen also Scheunentore offen, und darum ging's hier doch, oder? Ich meine, Du hattest doch gesagt, dass das nicht der Fall sei, zitierst aber in #70 doch wieder nötige Microcode-Updates? (ernste Frage, evtl. habe ich auch was überlesen)

 

[Atkatla]

Die Hoster, die ich kenne, migrieren VMs nicht ungefragt zwischen Hosts, von Billigstangeboten oder Serverless-Unsinn abgesehen.

Mindestens wenn die Hosts oder die Hardware gepatcht werden, müssen die VMs migrieren. Informieren die Hoster da jeden jedesmal? Ich glaube nicht. Als Hoster würde ich auch versuchen zu suggerieren, dass es keine Migrationen gibt und alles immer shiny ist. In der Praxis werden Migrationen aber durchaus bei Updates (egal ob Software oder Hardware/Firmware) oder bei veränderten Lastverhalten durchgeführt, was auch kein Problem ist, da es für die VM transparent und nicht bemerkbar ist (sofern der Cluster sauber designt ist). Es mag durchaus sein, dass für bestimmte VMs mit sehr hohen SLAs derartige Migrationen abgestimmt werden müssen, wenn die paar Millisekunden Stun-Time beim finalen Switch-over ein Problem sein sollten. Aber den Großteil aller VMs betrifft das nicht. Wir betreiben z.B. eigene Cluster und fahren beim Großteil der VMs nach der Devise: der Cluster darf die VM dann migrieren, wenn durch veränderte Lastverhalten ansonsten die VM negativ beeinträchtigt wäre. Auch die Cluster von Partnereinrichtungen sind meistens derartig konfiguriert. Es ist auch die BestPractice-Empfehlung von unserem Hypervisor. Aber um zum eigentlichen Thema zurück zu kommen:

Und im Paper steht insbesondere, dass man auch Hypervisor-Speicher auslesen kann. Da hat man dann allen Kontext, den man sich wünschen kann.

Als dieser Angriffstyp in der Form noch funktionierte hattest du zwar Inhalt, aber noch keinen Kontext, was diese Information bedeutete. Du liest Adresse X aus und hast dann eine bestimmte Bitfolge. Und dann? Zu welcher VM gehört die Information? Und selbst, wenn man das wüsste, kommt die nächste Stufe: welchem logischen Speicherbereich in der VM gehört die Information? Du hast ja nicht den kompletten Speicher des Hypervisors ausgelesen und Überblick über alles.

Meistens braucht man es aber ohnehin andersrum: der Angreifer sucht bestimmte Informationen. Nur unter welcher Adresse findet sich die Information? Blind mit 2 kbyte/s in mehreren hundert GB bis TB-Speicherbereichen zu suchen, wo die Inhalte sich mit sehr viel höherer Geschwindigkeit ändern, hilft auch nicht weiter.

Ohne entsprechende Gegenmaßnahmen stehen also Scheunentore offen, und darum ging's hier doch, oder? Ich meine, Du hattest doch gesagt, dass das nicht der Fall sei, zitierst aber in #70 doch wieder nötige Microcode-Updates? (ernste Frage, evtl. habe ich auch was überlesen)

Ich sage nicht, dass die Gegenmaßnahmen und Updates unnötig sind. Die Gegenmaßnahmen verringern die möglichen Angriffsvektoren. Auch wenn ein Angriffsvektor in der Praxis kaum ausnutzbar ist, sollte er geschlossen werden. Auch waren diese Vektoren kein Scheunentor. Sondern ein sehr schwer ausnutzbarer und wenig bringender Angriffsvektor. Ein Angriff, wo ich hoffen muss, dass das Ziel auf dem selben Host ist, der Host und der Hypervisor ungepatcht sind und ich noch gar nicht weiss, was ich wann unter welcher Speicheradresse auslesen muss, ist nicht sehr praktikabel und nutzbar.

 

[GrumpyCat]

Mindestens wenn die Hosts oder die Hardware gepatcht werden, müssen die VMs migrieren.

Du hast ein paar Posts hoher argumentiert, dass das ständig passiert. Tut's halt nicht.

Du liest Adresse X aus und hast dann eine bestimmte Bitfolge.

Das macht man halt ein paar Stunden lang, und wenn man irgendwelche Canaries à la ":$1$" oder ähnliches findet, schaut man genauer hin. Kann man alles automatisieren, genau das machen die Black Hats ja auch. Das Verfahren mag dann kompliziert sein, aber wen interessiert's, wenn das alles ein schönes Framework für einen übernimmt. Das passiert bei anderen Vulnerabilities ja auch so (welcher Exploit der letzten Jahre benutzt weniger als drei Löcher der Reihe nach?).

 

[Atkatla]

@GrumpyCat : Bzgl der Migrationen: ich habe gesagt, dass es passiert. Nicht dass es mit einer einzelnen VM ständig oder ununterbrochen passiert. Da wäre tatsächlich was mit dem Cluster nicht in Ordnung.

Und nehmen wir mal einen Cluster an, der diesbezüglich nicht gepatcht oder angepasst ist: in 24 Stunden hast du mit dieser Variante gerade mal 169 MByte von XXX Gigabyte oder Terabytes des Hosts gelesen. In dieser Zeit sind die Adressen u.U. schon wieder x-mal überschrieben worden. Zusätzlich besteht weiterhin das Problem, dass es dir nichts nützt, wenn du da irgendwo etwas wie ":$1$" gefunden hast, aber nicht weisst, zu welcher VM das gehört oder in welchem Kontext dies dort vorhanden ist. Da ist die Gefahr doch viel zu hoch, an Honeypots zu geraten.

Da gehen die Angreifer doch lieber mit Zero-Day-Attacken in die Zielnetze. Dann haben sie wenigstens die Informationen und Kontrolle. Denn solange Software von Menschen geschrieben wird, wird sie fehlerhaft sein und immer irgendwo Einfallstore bieten.

 

[lynx007]

Das die das machen ist mir klar, aber um wie von aikatv beschrieben von einem PC über das Stromnetz einen anderen PC mittels der Spannung zu hacken muss man:

• In einem relativ unbekannten PC in dem sonstwas für eine Spannungsversorgung selbige steuern
• In einem unbekanntem Stromnetz Spanungsschwankungen auslösen, die ...
• An einem relativ unbekanntem PC eine Reaktion auslöst, welche ...
• In einer unbekannten Spannungsversorgung die Spannung im PC so verändert, dass ...
• Der PC die geänderte Spanung als Signal akzeptiert und auch versteht, was da gesendet wird

Da sind halt Unmengen an Unbekannten drin.

Nur eine Frage der Anzahl der Würfel und der Anzahl der Würfe Und alles ist ja auch nicht unbekannt für Jemanden der sich mit der Materie täglich beschäftigt. Beim rest Würfelt man. Und wen man der erste ist, ist das auch äußert lukrativ. Man braucht eigentlich nur massiv Rechenleistung, Zeit und natürlich auch Glück. Den Exploit Shellshock den über Fuzzy 2014 gefunden hatte, existierte zb. 22 Jahre.

Zum Glück hat das bei Epic nicht ganz so lange gedeuert. Zmindest bei dem Exploit den wir jetzt kennen

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[GrumpyCat]

In dieser Zeit sind die Adressen schon wieder x-mal überschrieben worden.

Wieso? Gerade wichtige Credentials werden ständig angegrabbelt, also nicht ausgeswappt.

Aber es gibt ein paar ganz gute Userspace Mitigations, z.B. verschleiert OpenSSH soweit ich mich erinnere Credentials seit einiger Zeit bzw. verteilt sie im Speicher oder sowas. Ist aber nur ein Tropfen im Ozean.

 

[.Sentinel.]

Wieso? Gerade wichtige Credentials werden ständig angegrabbelt, also nicht ausgeswappt.

Es geht um die Verwertung dieser Daten und der Exploit braucht auch einen Rahmen, in dem er eine gewisse Sicherheit herstellen kann, dass die Bitfolgen tatsächlich konsistent sind.

Wenn Du eine geschäftige VM hast (nebst dem, dass alle Sicherheitsmaßnahmen, die Atkala bereits genannt hatte, ausser Acht gelassen haben musst), wird der Angriff langsamer und der Fehlerfaktor mit zunehmender Load noch höher.

Wie bewertest Du, dass das, was Du da gerade abgefischt hast, zu einem der wichtigen Credentials gehört?
Wie wahrscheinlich ist es, dass Du genau die richtige Adresse erwischst bei oftmals 700+GB an RAM, die physikalisch vorhanden sind?

Dazu musst Du im Hintergrund auch laufend eine Mustererkennung bzw. Heuristik am Laufen haben, die aber bei den kurzen Sequenzen, die Du lesen kannst sehr sehr sehr unwahrscheinlich auf irgendwas brauchbares stoßen wird.

Und- Der Arbeitsspeicher würfelt doch öfter mal durch. Da muss z.B. nur ein Windows Wartungslauf bzw. eine garbage- collection laufen, schon steht alles auf dem Kopf. Und das läuft minimal ein Mal am Tag.

Es bleibt dabei- Die Sicherheitslücken sind mit einer extrem hohem Wahrscheinlichkeit nicht gewinnbringend zu nutzen. Jede andere Methode ist einfacher und Erfolgsversprechender...

 

[Piktogramm]

Ich kann mir schon vorstellen, dass AMD diese Luecke schliessen kann, aber was ist dann mit den EPYCs mit dieser Luecke? Alle aus der Cloud herausschmeissen und an die Leute verkaufen, die ihren Admins vertrauen?

Die Systeme laufen bis sie regulär ausgetauscht werden. @.Sentinel. hat vollkommen recht, dass andere Vektoren deutlich problematischer sind.

Das ist mir bisher tatsächlich entgangen. Wo findet man da genaueres?

Wikipedia? https://de.wikipedia.org/wiki/Seitenkanalattacke#Glitch-Attack
Grundlegend ist die Thematik so alt wie digitale Logikschaltungen, damals noch als Problem und wenig später Werkzeug für "kreative" Techniknutzung

 

[GrumpyCat]

Wie wahrscheinlich ist es, dass Du genau die richtige Adresse erwischst bei oftmals 700+GB an RAM, die physikalisch vorhanden sind?

Außer bei einem gezielten Angriff gibt es doch gar keine "richtige" Adresse, da wird ggf. einfach automatisiert alles abgefischt, was erreichbar ist, und wenn's HTTP POST-Daten sind oder SSH-Keys oder tatsächliche Dokumente oder E-Mail-Adressen oder oder oder.

Davon ab wette ich, dass man bei freiem langsamem Zugriff auf physisches RAM haufenweise Software-Leaks nutzen kann, um Rückschlüsse auf das Mapping zu ziehen. Andere Exploits müssen ähnliches schließlich auch machen, mit ggf. stärkeren Einschränkungen.

Grundsätzlich hast Du aber schon recht, zufällige Angreifer werden im Moment eher Miner oder ähnlichen Krams laufen lassen als viele Ressourcen auffällig zum Abgreifen von Daten mit fraglichem Wert abzuzweigen.

 

[der Unzensierte]

Ich sag´s mal so - interessanter Angriffsvektor, in der Praxis aber wohl eher irrelevant. Wenn physischer Zugriff besteht ist kein System dieser Welt sicher. Ein krimineller Admin (oder auch nur user) ist immer ein Sicherheitsrisiko.