Todos os que frequentam o #linuxhelp @ ptnet já devem ter levado com a propaganda do sr fractalg sobre o seu porsche, ele faz isto, ele faz aquilo, ele passa por este na A1, passa pelo outro, o que é verdade é que tal carro nunca foi visto… nem só uma piczinha….
Após árdua pesquisa consegui encontrar a dita foto do carro aqui fica:
A noticia chegou-me pelo IRC, também já estava mais que sabido, ele próprio já tinha escrito no site dele que não ia durar mais que umas semanas. Pelo que a Wikipedia diz foi ontem, dia 3 de Maio 2009.
É uma grande perda para comunidade de RE de todo o mundo e não só, pois ele não se dedicava só a essa arte. Para mim, ele e o tKc foram como um senseis do cracking (que não domino assim tanto) que me meteram o bichinho, de ver como as coisas funcionam _under the hood_.
Vou actualizar de novo o mirror que tenho site dele em http://fravia.blol.org para não se perder caso o servidor onde o site dele ta alojado na suíça vá com os porcos.
Lembram-se de todo o drama quando criaram certificados falsos a partir de colisões de MD5?
Aparentemente a resposta dos principais CAs foi rapidamente migrar para SHA-1, mesmo sabendo que já não era inteiramente seguro (reparem na data). Na altura eu disse que era má ideia, mas agora a situação piorou:
SHA-1 Collisions now 2^52. Infelizmente o artigo completo ainda não foi publicado, deixando os detalhes do ataque em aberto. Ainda assim, os autores são credíveis e os resultados vão ser apresentados na Eurocrypt 2009 pelo Greg Rose, autor de um dos candidatos ao SHA-3.
Para quem argumentar que este tipo de ataques não é practicável, vamos fazer as contas (tm). A implementação do SHA-1 presente no OpenSSL precisa de cerca de 768 ciclos num processador actual (Q6600). Isto num processador de 3 GHz e 4 cores dá-nos cerca de 16 milhões de iterações por segundo, i.e. ~2^24. Num único processador, isto levaria demasiado tempo, cerca de 8 anos. Mas num cluster de 1024 destes processadores, não tão incomum quanto isso, levaria cerca de 3 dias. Isto ignorando implementações optimizadas para o efeito e chips mais apropriados para o efeito, e.g. Cell, GPU, FPGA, ASIC, …
Assim, recomendo Calgon em todas as lavagens que o SHA-1 deixe de ser utilizado para assinaturas digitais. Para autenticação simétrica (e.g. HMAC) e geração de números aleatórios estes resultados são de relativamente pouco interesse.
P.S. Esta implementação parece atingir os 213 ciclos por compressão, diminuindo drasticamente os custos descritos acima.
Ora viva amigalhaços!
Venho deste modo falar de um drama que aconteceu, que me deixou um bocado triste.
No sábado passado fiz um pedido para ser adicionado ao agregador português de blogs, o Planet Geek, disseram-me que iam fazer uma votação com os membros actuais para saber se o nosso blog poderia entrar ou não.
Fiz este pedido, por desde já uns tempos o blog está a ter vários posts diariamente e muitos deles com conteúdo, pode se dizer, MUITO geek, e gostava que tivesse mais um pouco de exposição do que tem actualmente.
Hoje depois de mandar um email a perguntar pela resposta, pois ainda não tinham dito nada, recebi isto:
Como acho que já estão recolhidas opiniões suficientes, tenho de te informar que a resposta é negativa, muito em parte pelo conteúdo anterior do blog no que respeita ao Mário Gamito.
Isto parece me um bocado hipócrita, porque enquanto o Gamito cá estava ninguém gostava dele, e montes deles gozavam com o homem… Agora que se passou o que se passou, são todos amiguinhos e defendem-no. Deviam ter feito isso enquanto ele cá estava e não agora, não acham amiguinhos?
Fiquei um bocado triste pois, um pedido sem malícia foi acusado de troll e tal, é cagar e andar! Como o cantor Fausto diz numa musica de 1977 “E assim se faz Portugal, uns vão bem e outros mal”.
Fiquem bem e joguem muito!
Oi.
Capitão COVIL
Esta é uma dedicatória aos verdadeiros homens da cave : Dcoder e falso.
Ora viva amigos.
Andava agora de volta do google à procura de arvorezinhas e achei uma coisa que me deixou a sentir violado.
Vejam este link do portugal-a-rippar, parece que um tal de Dumpster, em menos de 35 minutos conseguiu ripar a minha arvorezinha de x86 e trocar os nomes das variaveis e labels. Nem o titulo se dignou a mudar, chamou-lhe arvorezinha tambem. Alem do mais que fez isto tudo, enquanto a namorada shemale dele tomava um granda golden shower do Reinaldo. Porque será que não fez a arvore completa?
Como já não blogo há muito tempo decidi vir falar sobre algo completamente inutil. Estava eu a tentar compilar o ircd da ptlink no OpenBSD com o pcc em vez do gcc, quando me deparo com um erro meio estranho…
pcc -I../include -g -O2 -DNDEBUG -c help.c
pcc -I../include -g -O2 -DNDEBUG -c hvc.c
hvc.c, line 100: return value required
*** Error code 1
Achei estranho este tipo de erro, ate porque isto é compilavel em outras circunstancias.
int m_hvc(aClient *cptr, aClient *sptr, int parc, char *parv[])
{
if(!IsPrivileged(sptr))
return; /* Linha 100 */
if(parc < 2)
{
if(MyClient(sptr))
Nunca tinha visto “return;” em nenhum codigo na vida, e fiquei a pensar como é que o gcc papa isto sem espinhas. Pus return 0; porque me pareceu bem e o resto do programa compilou bem, mas depois deu problemas a linkar portanto cagay naquilo. Fiz uma experiencia:
{:/home/bud/gcc:48} cat main.c
#include <stdio.h>
int sida() {
return;
}
int main() {
printf("%x--\n",sida());
return 0;
}
{:/home/bud/gcc:49} gcc -o sida main.c
{:/home/bud/gcc:50} ./sida
3bbc634d--
{:/home/bud/gcc:51} ./sida
5357df90--
{:/home/bud/gcc:52} ./sida
b3e1e9d9--
Belo random number generator :-P Com -Wall o gcc ja diz qualquer coisinha
main.c: In function `sida':
main.c:4: warning: `return' with no value, in function returning non-void
Acho que supostamente isto nao devia funcionar? O dcoder teve me a dar umas dicas e disse que o msvc tambem comia os return;. Bastante inútil este post, hein?
Everyone needs cryptographically strong pseudo random numbers in this day and age. From card games to your Paypal HTTPS session, it has become an essential part of secure systems. Now, as a user it’s hard to generate randomness; we all know how many systems are seeded with time(NULL) or the like. That’s why most operating systems have mechanisms to provide randomness to the user. In Unix systems, this is usually done through /dev/?random; on Windows, through the function CryptGenRandom.
However, CryptGenRandom requires a handle to a CSP (acquired by calling CryptAcquireContext). If all we want is random bytes, this no good; a full-fledged CSP takes too many resources (and time to load) for the task at hand. So an alternative is to use the lower level function RtlGenRandom, which doesn’t require a CSP context. This name is an actual alias for the function ‘SystemFunction036’ in advapi32.dll. MSDN reports: “This function has no associated import library. This function is available as a resource named SystemFunction036 in Advapi32.dll. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Advapi32.dll”. But what if we don’t want the pain of loading and unloading libraries at runtime? I’ll show you how to make the required import library to avoid this.
The main problem you will encounter is that RtlGenRandom’s calling convention is __stdcall, whereas its actual name in advapi32.dll does not reflect that (__stdcall functions have the number of bytes passed as parameters in the stack appended in the function name. In this case, it expects SystemFunction036 to be called SystemFunction036@8). Using the LIB utility doesn’t help, even when using aliases: it always expects the appended number of bytes to be there. So first idea is to use function ordinals. Running DUMPBIN /EXPORTS on advapi32.dll shows us:
621 26C 00008292 SystemFunction036 = _SystemFunction036@8
So now we know the ordinal of our function: 621. With this in mind, we can now use LIB to create a .lib to link against our application. First, create a .def file with the following lines:
LIBRARY advapi32.dll
EXPORTS
SystemFunction036@8 @ 621
Now run:
lib /DEF:RtlGenRandom.def /OUT:RtlGenRandom.lib /MACHINE:X86
Now you can just link the resulting .lib with your application to have the desired result.
However, this is not a good solution. Ordinals are by no means fixed (unless you’re dealing with Winsock2 or MFC dynamic libraries) and you have no guarantee they’ll be the same across Windows versions. So here’s another way to do it. First, create a C source file and declare an empty function equal to RtlGenRandom:
#include <windows.h>
#define RtlGenRandom SystemFunction036
#define DLLEXPORT __declspec(dllexport)
DLLEXPORT BOOLEAN WINAPI RtlGenRandom(PVOID in, ULONG len) {}
Now create a .def like the following:
LIBRARY advapi32.dll
EXPORTS
SystemFunction036
Now we compile the source and feed the DEF to the linker:
cl dummy.c dummy.def
The actual binary output of this compilation is irrelevant; what we want is the resulting dummy.lib. You can now link against this import library and it will link to the real advapi32.dll, thus giving us what we want. I used the following test source to try it out:
#include <stdio.h>
#include <windows.h>
#define RtlGenRandom SystemFunction036
BOOLEAN WINAPI RtlGenRandom(PVOID, ULONG);
int main(int argc, char **argv)
{
BYTE blah[20];
DWORD i;
RtlGenRandom(blah, 20);
for(i=0; i < 20; i++)
printf("%02X ", blah[i]);
return 0;
}
Compile with:
cl /O2 /MT test.c dummy.lib
Problem solved. Try it out.
PS: Someone’s bound to comment “oh but Windows’ PRNG is flawed, there was a paper on it some time ago”. That’s correct. However, both attacks (forward and backward security compromised) assume you already have knowledge of the whole state of the PRNG (i.e. you’ve owned the box) and that you’re running a Windows previous to XP SP3, which fixed the issue.
O FiSH é uma valente seca para se compilar - é um facto. Em particular quando se fala em compilá-lo num SO opensores numa arquitectura não x86. A biblioteca MIRACL que aquilo usa é essencialmente o problema aqui. Portanto a escolha lógica é acabar com esta biblioteca e usar uma ligeiramente mais decente.
Agora, a biblioteca em si não é nada má. Para fins criptográficos provê montes de coisas úteis que seriam feitas à mão de outro modo – números aleatórios seguros, curvas elípticas (e construção de boas curvas - poucas bibliotecas são minimamente úteis neste aspecto), além de possuir hashing (SHA-2) e encriptação (AES) incorporados. No entanto, o processo de compilação é absolutamente deixado ao acaso e a documentação é como deixar o Bear Grylls no deserto sem um hotel por perto.
Obviamente eu não fui o primeiro a ter esta ideia. Nos próprios fórums já foi sugerido múltiplas vezes esta mudança, e aparentemente alguém já a fez. Mas vamos lá olhar para este patch com olhos de ver:
int DH1080_gen(char *priv_key, char *pub_key)
{
…..+ mpz_t mpz_privkey, mpz_prime, mpz_pubkey, mpz_base;
+ gmp_randstate_t randstate;
// #\#\#\#\#\* RNG START #*#*#*#*#*
time((time_t *)&seed);
+ gmp_randinit_default(randstate);
+ gmp_randseed_ui(randstate, seed);
+ mpz_urandomb(mpz_privkey, randstate, 1080);
+ gmp_randclear(randstate);
seed=0;
// #\#\#\#\#\* RNG END #*#*#*#*#*
….}
Aparentemente o nosso génio, além de utilizar a função errada (deveria ser mpz_urandomm) para gerar números entre 0 e mpz_prime exclusive (mpz_prime sendo o primo que define o grupo onde estamos a trabalhar e por sua vez define a dificuldade do problema no caso de uma implementação em condições), não verifica se a chave pública criada é 0 ou 1 (o que arruinaria ligeiramente a segurança nesse caso estupidamente remoto). Mas aqui a maior falha é utilizar a data do sistema como seed para a chave privada. Sim, todas as chaves possíveis criadas com este patch estão dependentes de um valor de 32 bits (que na prática pode ser reduzido muito mais – é um timestamp). Parece-me que alguém não faz ideia do que está a fazer (aparentemente uma situação generalizada na indústria da segurança, diga-se de passagem).
Mas enfim, não se pode apenas criticar. Com o intuito de parecer ligeiramente menos hipócrita, coloco aqui a minha própria modificação que utiliza um método ligeiramente mais seguro para a geração de chaves (no código original, era criado e seedado um novo csprng por cada troca – qual a necessidade?). Utilizo a cifra ISAAC para a geração de números aleatórios (não se pode ser muito mais judeu que isto, eh?), e esta é alimentada com 256 bytes do /dev/urandom (caso queiram portar para Windows podem facilmente utilizar a RtlGenRandom) misturados com a SHA-256 do blow.ini e do irssi.conf. É então gerado um número e certificamo-nos que este se encontra no intervalo [2; prime1080-1].
Para a aritmética uso a GMP. Alterei apenas o plugin para irssi, mas quaisquer alterações são facilmente movidas para as outras versões. Deixo o licenciamento para quem não tem mais nada em que pensar.
Nota: Se estiverem a usar Ubuntu e não conseguirem compilar, a culpa não é minha.
Nota2: Se são verdadeiramente paranóicos, estão a utilizar a ferramenta errada. A troca de chaves como é implementada no FiSH (puro Diffie-Hellman) é vulnerável a ataques man-in-the-middle, uma vez que não existe qualquer autenticação; se querem algo minimamente seguro, talvez o SILC não seja um mau começo.