Tópico da Apple

a verdade é que são.

pergunta a quem sabe: gente ligada à bitcoin e que percebe de encriptação e segurança a sério.

Mais outro fanboy que tal como o outro, só tem a apresentar a sua opinião pessoal aos factos [:D] e ignora o mundo à sua volta [:)]

Vou perguntar à malta do bitcoin? [:D][:)]MEGA LOL

A teórica mais segura arquitectura de sistema de nada te serve quando na realidade a teoria não se aplica na prática da vida do utilizador [:D]
Vide p.ex dados que já mencionei em cima......que fique bem claro que eu não estou a discutir filosofias de arquitectura UNIX vs MSFT.......

Estou a afirmar sem medos que o OSX não é um Sistema Operativo mais seguro que Windows 10, nem o IOS é um Sistema Operativo mais seguro que o Android.




Este teóricos com palas divertem-me à brava[:)]
 
Última edição:

[:)] [:)] [:)] [:)]

Achas que é por repetires aquilo que prova que és um teórico que ganhas prática?
[:)] [:)]


Continuas sem compreender a razão, pelo simples motivo de não saberes o que é uma
vulnerabilidade, como se encontra, e muito menos como se explora.
Se soubesses (assembly), há muito que terias acabado com o disparate (próprio de teóricos)
de fazer contagem de vulnerabilidades.
Continuas sem perceber o contexto das vulnerabilidades, e da possibilidade REAL (e não
teórica) na exploração com sucesso das vulnerabilidades.
Para além disso, achas que a contagem de 5 meses de vulnerabilidades em 2015 (W10)
pode ser comparada com uma contagem de um sistema que já lá estava desde Janeiro (OS X).
[:)]


Exemplo:

Diz-me, como se exploram (possíveis vectores de ataque), e quais as condições que devem
estar presentes, para ser possível explorar com sucesso as seguintes vulnerabilidades.

Depois diz-me qual das duas vulnerabilidades apresenta maior risco, e porquê.

APPLE (CVSS Score = 10):
https://www.cvedetails.com/cve/CVE-2015-5780/
The Safari Extensions implementation in Apple Safari before 9 does not require user confirmation before replacing an installed extension, which has unspecified impact and attack vectors.

MICROSOFT (CVSS Score = 9.3)
https://www.cvedetails.com/cve/CVE-2014-1818/
GDI+ in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT Gold and 8.1, Office 2007 SP3 and 2010 SP1 and SP2, Live Meeting 2007 Console, Lync 2010 and 2013, Lync 2010 Attendee, and Lync Basic 2013 allows remote attackers to execute arbitrary code via a crafted EMF+ record in an image file, aka "GDI+ Image Parsing Vulnerability."

[:)] [:)] [:)]

Acho que me vou divertir bué...
 
(...)
Este teóricos com palas divertem-me à brava[:)]

O mais giro nisto é chamares teóricos aos outros...
[:)]

Não sei porquê, as questões que coloquei continuam sem resposta...
Sabes qual é a verdadeira diferença entre teóricos e os que efectivamente percebemde segurança? Os que percebem efectivamente de segurança, para além da teoria,
sabem programação de baixo nível (a fundo, e não academicamente). Tu sabes?
E quantos hackings é que já fizeste sem te baseares em hackings feitos por outros?
E quantos fizeste ainda antes de haver Internet (para procurar ajuda online)?

Resumindo:
Não sabes o que é uma vulnerabilidade (em termos práticos), e por isso não sabes como
se explora, e não sabendo como se explora não fazes a mais pálida ideia do impacto que
tem a nível de segurança.

Ou seja, para ti, uma janela no rés-do-chão é igualzinha a uma janela no 69º andar.
Qualquer um compreende isto numa casa, o que podem não compreender (e tu não
compreendes) é a implicação disto nos computadores (ou seja, não percebes a analogia).

Mas vou tentar explicar:

São duas janelas iguais. Dimensões, vidros, molduras, mecanismos de segurança, etc.
Ou seja, são duas vulnerabilidades iguais, com o mesmo CVSS Score, com as mesmas
condicionantes, com a mesma complexidade, com o mesmo âmbito de danos, etc.

A diferença está na altura. Uma está no rés-do-chão, outra está no 69º andar.
Ou seja, uma está acessível através do router, NAT, firewall, etc., enquanto a outra não
está acessível.

O que tu ainda não percebeste, e pelos vistos não vais conseguir perceber, é que entre
a TEORIA de exploração de uma vulnerabilidade, e a PRÁTICA de conseguir efectivamente
explorar uma vulnerabilidade, vai uma ENORME distância.

Daí que, as vulnerabilidades nos browsers sejam muito mais graves que as vulnerabilidades
num kernel (por exemplo), INDEPENDENTEMENTE DE TEREM UM SCORE MENOR que as do
kernel.

Mas pronto, não espero que um teórico chegue lá... mas não custa nada tentar.
 
Podes andar aqui às voltas o tempo que quiseres já percebi que só atiras areia para os olhos [:)][:D], se te faz tanta impressão a comparação do OSX com as vulnerabilidades do W10 compara com o W8.1 [:)][:)]o OSX volta a ter mais vulnerabilidades de risco alto ou médio em 2015 [:D][:)] ou do IOS com as do Android como eu já fiz [;)]

W.8.1

https://www.cvedetails.com/vulnerab...&sha=4dcb1b5e5ffd85d91769badd9483efd405c1e090

OSX

https://www.cvedetails.com/vulnerab...&sha=ebdd00d8f2dc46ff6a5f6338bf40b5a0a9f0a719

Resumindo a Apple tem em comparação com a concorrência sistemas operativos com mais vulnerabilidades de risco médio e alto e tem o mais ineficaz e lento ciclo de patching face à concorrência, já para não falar numa politica de segurança menos agressiva face à MSFT p.ex.....

E o mais assustador disto tudo é que nem o OSX nem o IOS são quem domina os respectivos mercados, imagino o passador autêntico que não seriam estes SOs se não fossem apenas uma pequena minoria no mercado de SOs e toda a gente quisesse cascar neles [:D]

E por favor para, que já não aguento de tanto rir, só te enterras[:D]
 
Última edição:
Pode ser que quando tirares as palas e não andares às voltas a dizer que o OSX e IOS são por si sistemas operativos mais seguros que a concorrência, eu perca mais tempo contigo [;)][:)][:D][:)][:)][:D][:)]
 
Fazer a lide a fanboys é peaners [:)][:D]

Olé:

http://www.tripwire.com/state-of-se...body-really-care-about-vulnerability-scoring/
Does Anybody Really Care About Vulnerability Scoring?

I’ve been involved in vulnerability scoring discussions more times than I can count. Colleagues, customers, conference-goers, and complete strangers all want to discuss the topic and I can’t say I blame them… the topic is interesting.


So after numerous blog posts on other subjects, it’s probably time to tackle the issue in an open forum where we can discuss and debate as a group.


Let’s start with my feelings on scores since I should probably be upfront about it. The current state of vulnerability scoring is useless. With the frequency of vulnerability disclosure and the number of vulnerabilities patched in products, a bucket consisting of High, Medium, and Low tells me nothing.


The solution to our scoring problems was supposed to be CVSS. It provides more buckets and looks, at least initially, as though it distributes the scores quite well. In reality, the 100 buckets of CVSS is really more like 15-20 as certain scores become commonplace and others are never seen.


Let’s take two vulnerabilities, A and B. Vulnerability A has public exploit code and targets a popular operating system. It is a remote unauthenticated attack against the network stack and leads to a total compromise of the system.


CVSS Score: 10.0
CVSS Vector: (AV:N/AC:L/Au:N/C:C/I:C/A:C)
Vulnerability B has no public exploit code and targets a popular web technology. It requires that a user browse to a website and, if an exploit existed, successful exploitation would lead to code running in the context of the user, not the system.


CVSS Score: 10.0
CVSS Vector: (AV:N/AC:L/Au:N/C:C/I:C/A:C)
As you can see both of these have CVSS Scores of 10.0. This is why I see these system as useless. When you read the details, it’s very easy to identify a priority but if you were to rank these by CVSS, that priority would disappear.


So what is the solution? In my mind it’s risk scoring. When you’re talking about a vulnerability, the risk score is what you should care about. What we really need is CVRSS but it doesn’t exist (hrm… maybe an upcoming blog idea).


When you look at public systems, no one is really doing this. Microsoft has come close but they still aren’t there. If they could find a way to marry their severity score with their exploitability index into a single value, I think they’d provide a useful way to truly prioritize Microsoft bulletins.


I think this is something that everyone in the vulnerability management space is currently dealing with as well. Helping customers prioritize vulnerabilities is a large part of our job and no one has figured out the perfect way to do it yet. Some companies are still scoring vulnerabilities, other companies are just using CVSS, and others still, Tripwire included (via the nCircle acquisition), have worked at risk scoring but still haven’t perfected it.


At Tripwire, we look to score the risk using three factors: age of the vulnerability, exploit availability, and resulting level of access to the system. If I do a follow-up blog post on a proposed CVRSS, I would leave these in but I would likely improve the process with a few additional factors. When you look at the elements used by Tripwire, they all make sense, especially exploit availability and level of system access.


If an exploit is available, a vulnerability should score higher, and if that exploit is in malware or a known exploit framework it should score even higher. The same is true when you look at the level of access… a vulnerability that leads to user level access should not score the same as a vulnerability that leads to system level access. These factors make a world of difference when you’re looking at a list of 10,000 vulnerabilities trying to decide which ones to patch first.


If you look at the above Vulnerability A and Vulnerability B examples, using Tripwire ’s scoring system, Vulnerability A would receive a score of 24,203 and Vulnerability B would receive a score of 1. From this difference, it is quite easy to determine a priority for applying patches.


In an effort to further improve our scoring, Tripwire (again, via the nCircle acquisition) released a number of ASPL-Based scoring changes last year. These are flags that the customer can set to further prioritize their vulnerability scan results.


These flags can be thought of as the environmental portion of a proposed CVRSS, allowing more control over the results that are important to you. Customers interested in learning more about this can contact Tripwire for details or sign up for The State of Security publication.


After this much writing, I’ll probably have to do a follow-up post on risk scoring… but I wanted to get something posted simply to start the discussion. So… discuss!

Mas aposto que nem assim vais compreender.
Aliás, quando se repete até à exaustão contagens de vulnerabilidades (por score ou não),
e se pensa que a quantidade de vulnerabilidades (e não a sua explorabilidade) define algum
grau de segurança que seja, é mesmo de quem percebe ZERO do assunto.

Razão pela qual eu disse que o artigo da PPLWARE era de quem sabe ZERO sobre o assunto,
ao contrário dos gajos da VENTURE BEAT, que dizem:
Again, this list paints a picture of the number of publicly known vulnerabilities, not of all vulnerabilities, nor of the overall security of a given piece of software.
http://venturebeat.com/2015/12/31/so...ios-and-flash/

Sinceramente, não vale a pena continuares a insistir. Não é por insistires que passa a ser
um facto. Aprende primeiro assembly a sério (as speaking a second language), e depois
falamos.
 
Nuno, dont feed the troll.
Ignore list.

Como disseste e bem: serve para colocar mais informação sobre o assunto, para
quem quiser entender mais um pouco sobre estas coisas.

Só tenho pena é que estes links e temas (PPLWARE e encriptação) tenham sido
colocados aqui (tópico da Apple), e não no tópico apropriado (segurança da
informação), com links daqui para lá.

EDIT:
Ainda assim, o artigo que citei no último post está "curto". Na realidade, a não
existência de exploits conhecidos não implica que não existam exploits activos.
O que é realmente importante incluir na classificação é o CONTEXTO de exploração
das vulnerabilidades, ou seja, a sua explorabilidade. Isto é, até que ponto um
exploit pode ser realizado em condições reais (e não de laboratório). Ou seja, as
condicionantes reais que se devem verificar para que se possa fazer o exploit.
 
Última edição:
É escusado Nuno.....quando aprenderes a olhar para este tema mais a sério, sem palas e numa óptica mais adequada à vida real, eu volto a perder tempo contigo, até lá não é com copy paste que lá vais......
Já expus o meu ponto de vista e justifiquei com factos medidos e palpáveis na indústria actual, tu insistes em especulações e marrar em teorias ignorando a realidade sobre os gravissimos problemas de segurança actuais e a falta de procedimentos de patching mais eficazes da apple face à concorrência....olha azareco, problema teu[:D][:)]

Junta-te ao teu amigo fanático e vão perguntar ao pessoal dos bicoins e façam de conta que nada se passa como tem feito a apple nestes últimos anos[:D][:)]

Como já disse o que ainda vai safando a coisa é serem SOs de minorias.....
 
Última edição:
Uma questão é normal os produtos da apple ficarem tão lentos? Tenho um ipad mini primeira geração (do qual até gosto muito) mas isto de há um ano para cá não se arrasta! Há forma de melhor isto? Já me disseram que o segredo é não atualizar mais que 1 versão acima. Eu até considerava outros produtos da marca (outro ipad ou sté um iphone que o meu tlm já pede troca) mas se pelo preço que pedem só é expectável que se mantenham rápidos por cerca de 2 anos não sei se será boa opção.

cumps
 
Voltar
Superior