Newsgroup: it.comp.sicurezza.varie
Titolo: Come jammed the COM port in Windows...

FYI
Per chi usa il modem, ed usa Windows, c'e' un modo molto semplice per
bloccare la COM port.
Se il modem e' su COM1, lancia il command line e digita: c:>edit com1. I
risultati non si faranno attendere.
A dimenticavo, questo comando puo' essere eseguito anche dal Guest
account...
K
-- 
-- 
<<And if all others accepted the lie which the Party imposed -if all records
told the same tale -- then the lie passed into history and became truth.>>,
George Orwell, 1984.

 com1. I risultati non si faranno attendere.
ma quali risultati?
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
                               and beta testers are welcome!

 ma quali risultati?
Lo so come funzionano le porte...Hai provato prima di rispondere a questo
post?
K


type it in CMD prompt or "RUN" etc... Using this Any/EVERY available
communication port's in WINDOWS could be JAMMMED! By using JUST the
privileges of a "GUEST" account.
---Summery---
The exploits have been successfully tried in Windows xp pro. and windows 98.
I assume! It works in all versions of windows. While trying the exploit THE
COM* should not be in use.
---[Background Information]---
These bug's were originally discovered by hUNT3R, [myself] a member of 01
Security Submission. The vendor was notified via email.
http://www.ysgnet.com/hn
K

 ma quali risultati?
DoS
-- 
HappyCactus - Linux User #209744 - 
 
www.google.com
 - 
groups.google.com

 com1. I risultati non si faranno attendere.
C:\WINDOWS>edit com1.
   File  Modifica  Cerca  Visualizza  Opzioni  Guida
+------------------------------ C:\WINDOWS\COM1 ---------------[...]--+
|                                                              [...]   
|                                                              [...]  _
|                                                              [...]  _
   File  Modifica  Cerca  Visualizza  Opzioni  Guida
++----------------------+------ C:\WINDOWS\COM1 ---------------
|| Nuovo                |
|| Apri...              |
||>Salva                |
|| Salva con nome...    |
|| Chiudi               |
|+----------------------|
|| Stampa...            |
|+----------------------|
|| Esci                 |
|+----------------------+
   File  Modifica  Cerca  Visualizza  Opzioni  Guida
+------------------------------ C:\WINDOWS\COM1 ---------------
|
|
|
|
|
|
|
|                                  Modifica
|
|                    Impossibile creare o accedere al file
|                              'C:\WINDOWS\COM1'
|
|                    Riprova  _    Annulla  _       Guida  _
|                   ___________   ___________       ________
|
|
|
   File  Modifica  Cerca  Visualizza  Opzioni  Guida
++----------------------+------ C:\WINDOWS\COM1 ---------------
|| Nuovo                |
|| Apri...              |
|| Salva                |
|| Salva con nome...    |
|| Chiudi               |
|+----------------------|
|| Stampa...            |
|+----------------------|
||>Esci                 |
|+----------------------+
C:\WINDOWS>edit com1.
C:\WINDOWS>exit
E quindi?
Ciaotutti,
* e un bug patchato ormai da anni
--
Per scrivermi in email aggiungete un tag [PRI] al soggetto, altrimenti
il messaggio verra' automaticamente cassato.
To write me in private mail add a [PRI] to the subject, otherwise the
message will be automatically deleted.

 DoS
Si' ma sto bug ha l'eta' di Windows 95, e' stato scoperto tipo nel 2000, ed e'
stato corretto pochi mesi dopo.
Molto piu' divertente e' questo:
begin 644 t.htm
E/$A434P^#0H\24Y0550@5%E012!#4D%32#X-"CPO2%1-3#X-"@
`
end
Prima che qualcuno salti su con la storia degli allegati, trattasi di un file
HTML di 3 (tre) righe, uuencodato per la comodita' dei lettori che usino OE, i
quali con un semplice doppio click vedranno un bel botto ;) Visto che il tutto
pesa tipo una riga di testo, una volta uuencodato, non si qualifica come
attachment in senso stretto.
Per quanti non lo vedano, l'HTML e':
<HTML>
<INPUT TYPE CRASH>
</HTML>
Enjoy!
Patchato (credo) in IE 6.
Ciaotutti,
*


 post?
Io non ho capito, posso chiederti cosa capita di strano?

 wrote in message
news:Xns9400E451448CFvi...@195.31.190.132...

Happy Cactus ha gia risposto: DoS.

 Happy Cactus ha gia risposto: DoS.
Lo chiedo anche a lui, denial di quale service?

 Patchato (credo) in IE 6.
Yes ;)
Provato tempo fa e funzionava... ora non piu' (Vedo un rettangolo vuoto).
IE6 SP1 + 5 Kg di Patch ;)))
Stef_Ozzy


OK, adesso COM1 e' lockata, quindi neanche l'amministratore puo' usarla.
Ovvero, evidentemente non si puo' negare a Guest l'accesso in lettura alle
porte COM.
Leonardo e vabbe'
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 wrote in message
news:Xns9400ECBC05F61vi...@195.31.190.132...

Di quello che sta operando su quella porta prima del giochetto...se su
quella porta c'e' un modem la trasmissione se ne andra' a fare benedire, se
c'e una weather probe che trasmette i dati temperatura/umidita', la
trasmissione di tali dati cessera'.
Non e' una nuova vulnerability...ma risulta essere ancora molto efficace...
K

 bloccare la COM port.
Fico.
Il le com le ho disabilitate da bios.
E il modem lo uso, ma e' interno.
A.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 2000, ed e' stato corretto pochi mesi dopo.
No, credo sia un'altra cosa. Quello a cui ti riferisci faceva crashare
il S.O., questo blocca solo la risorsa.


 E il modem lo uso, ma e' interno.
 
Che è mappato come una porta com.

 Che è mappato come una porta com.
Certo, solo che in questo caso la com e' software, ed e' attiva solo
quando viene attivato il modem.
Per poter exploitarla, in questo caso, dovresti prima trovare un modo per
attivare il modem (un intel ham).


 attivare il modem (un intel ham).
Per lo meno, io non riesco ad attivarlo: ottengo solo cannot access device.
Ovvio, che, se win non viene patchato, e' exploitabile lo stesso, solo
piu' difficilmente.


 Hai provato prima di rispondere a questo post?
ho provato, e non succede una beneamata mazza di niente


 DoS
ma di che? se il "Service" c'è, in primo luogo, la porta la usa lui. Al 
massimo si possono sempre cambiare i permessi della device (funziona)


 ho provato, e non succede una beneamata mazza di niente
Lucky you...
K

 efficace... 
queste sono quisquillie e pinzillacchere. Io ne ho scoperta una *vera*, 
di vulnerabilità, anzi, proprio un buco nel design: il filesystem delle 
named pipe non supporta le directory, il che significa che un qualsiasi 
idiota può rubare un nome di endpoint ad un servizio non ancora avviato 
e, se i client di questo servizio sono particolarmente boccaloni, anche 
svariate identità (limitatamente alla macchina locale, comunque. Per la 
delega - impersonazione sulla rete - serve un privilegio). Direte: come 
ha fatto Microsoft a cavarsela, finora? semplice: o i servizi che usano 
named pipe come endpoint vengono avviati all'avvio e non possono essere 
chiusi o i servizi *non* usano named pipe del tutto. La seconda opzione 
è sicuramente la migliore, ma i rischi nell'uso delle pipe, secondo me, 
non sono documentati adeguatamente, così tutti finiscono per sceglierle 
e possibilmente aprire falle di sicurezza


 lettura alle porte COM.
cerrrto che si può. Le porte COM son delle belle \Device\SerialX con la 
loro bella ACL, quindi tutto si può (appena provato). Il problema è che 
l'ACL non viene ricordata dopo un riavvio. E che eseguire comandi prima 
del login, in Windows, è più difficile di quanto dovrebbe essere (forse 
nelle Group Policy c'è qualcosa, non ricordo). E che nessuno, e ripeto, 
nessuno degli strumenti predefiniti per l'impostazione delle ACL (cacls 
e secedit) supporta i path a periferica (nel nostro caso: \\.\COMx). Si 
potrebbe dire che non si può, in definitiva


 di vulnerabilità,
<cut>
Questa non e' una vera vulnerabilita'...non so dove vuoi arrivare...se non
l'hai capita, affari tuoi...
Io, e altre persone abbiamo cercato di spiegartela...Vuoi fare la gara a chi
ne sa di piu'? Beh, hai sbagliato persona...non mi presto a questi
giochetti...passo e chiudo.
K

 (funziona)
Quel che pensavo.


 O non ho capito molto della vulnerabilita'?
Beh, se un programma sta usando una porta nessun altro programma puo'
usarla...
Tu chiamala se vuoi vulnerabilita' :)))
Ciaotutti,
*

 gara a chi ne sa di piu'?
come ho già detto ho carenze anatomiche congenite che non mi permettono 
di essere competitiva nelle gare a "chi ce l'ha più lungo". E' solo che 
m'è sgorgato spontaneo il ricordo di una vulnerabilità simile


 vince la mia (gnč, gnč, gnč)
Bravo! Ma ora continua ad usare il tuo dummy.
K

 efficace... 
Prego, scusa? Se la seriale è aperta dal weather probe o da un qualsiasi 
programma di comunicazione il mitico edit risponde che non può aprire il 
file. O no? L'accesso alla seriale è esclusivo e vale per tutti. Hai 
notizia che durante una comunicazione in corso fra un software e la seriale 
facendo "edit com1" la comunicazione si interrompe?
La "vulnerabilità" è dovuta al fatto che l'accesso alla seriale non è 
possibile (almeno secondo le mie conoscenze) permetterlo/vietarlo a livello 
di utente, con questo il programma X lanciato da guest può bloccare il 
programma Y di administrator. Ma siccome l'accesso alle seriali è 
*esclusivo*, il problema per come lo poni no esiste.
 


type it in CMD prompt or "RUN" etc... Using this Any/EVERY available
communication port's in WINDOWS could be JAMMMED! By using JUST the
privileges of a "GUEST" account.
---Summery---
The exploits have been successfully tried in Windows xp pro. and windows 98.
I assume! It works in all versions of windows. While trying the exploit THE
COM* should not be in use.
---[Background Information]---
These bug's were originally discovered by hUNT3R, [myself] a member of 01
Security Submission. The vendor was notified via email.
http://www.ysgnet.com/hn
K

 Bravo! Ma ora continua ad usare il tuo dummy.
ironia, chi era costei? Riproviamo con i fatti. Questa "vulnerabilità", 
o presunta tale, è solo una scelta opinabile di un default, che non può 
essere corretta in modo banale ma *può* essere corretta. Non capisco il 
punto di questo thread: è un problema che ti tocca? vuoi una soluzione? 
o è solo il solito "*sgomit sgomit* Windows fa proprio schifo, eh?" che 
sorbiamo quotidianamente fino alla nausea? Io ho fatto la mia parte. Ho 
dato la soluzione (quindi per me la discussione della vulnearabilità in 
questione è chiusa), e ho rilanciato per continuare la discussione


 While trying the exploit THE COM* should not be in use.
Minchia che exploit :PP
I cosi privilegiati (per dirla alla juliet) girano come servizi, ergo *prima*
che qualsiasi guest ossa accedere al sistema e cercare di accaparrarsi le
risorse.
La cosiddetta vulnerabilita' si traduce in: "con i privilegi di default di
windows, qualunque utente, anche guest, ha diritto di accedere alle porte di
comunicazione".
Well, duh!
Ciaotutti,
*

 lo possa leggere).
Io lo posso leggere, sei tu che dicendo 
<cite> 
se c'e una weather probe che trasmette i dati temperatura/umidita', la 
trasmissione di tali dati cessera'
</cite> 
hai dimostrato di non saperlo leggere. Ciò che dice è che un qualsiasi 
processo utente in windows può accaparrarsi la risorsa. Non dice che può 
farlo quando questa è già occupata.

 wrote in message
news:Xns9404DA32AEAD2vi...@195.31.190.131...

Hai provato?.. Ti ripeto che la trasmissione dei dati e' stata jammed dopo e
non prima. Per questo ho ritenuto il caso di postarlo. Ripetero' il test su
una diversa COM.
K

 Tu chiamala se vuoi vulnerabilita' :)))
Beh, insomma: Se un programma _non_ privilegiato puo' bloccare
indifinitamente una risorsa ad uso di un programma privilegiato, per me
e' una vulnerabilita', e anche grande.
Immagina che quella COM sia utilizzata a fini di autenticazione, per
esempio.


 me e' una vulnerabilita', e anche grande.
Se fosse "una risorsa" generica, si', ma una com port non e' una risorsa
generica, e' una risorsa specifica, con dei vincoli precisi.
Uno di questi vincoli e' il funzionamento "first come first serve", che fa
si' che nessun programma non privilegiato possa accedervi, in condizioni
normali, prima di un programma privilegiato (in quanto questi ultimi girano
come servizi).
Se un utente non privilegiato riuscisse a fermare il servizio privilegiato,
allora avremmo una vulnerabilita'... Ma non sarebbe l'uso della porta com,
sarebbe la possibilita' da parte di un utente non privilegiato di
interrompere un servizio di sistema.
Ora, non so come giri sotto linux (tutte le volte che ho usato le seriali
con cat e compagnia mi sono trovato con dei comportamenti a dir poco
inaspettati), ma se una porta non puo' esere condivisa non puo' essere
condivisa, e se un programma l'ha aperta l'ha aperta. Se un programma
privilegiato vuole prendersela, prima deve uccidere il programma non
privilegiato...
Ciaotutti,
*


(non mi piace moltissimo la soluzione, ma č sicuramente la piů indolore 
per i programmi esistenti)
