2011-09-07 5 views
0

Je liez bibliothèque liboauth avec mon application, à partir du fichier de vidage de base, il montre de oauth_sign_array2 il a commencé à utiliser pointeur non valide qui s'appelle l'intérieur de cette lib neSegmentation fault dans l'application

Ci-dessous bt pour l'application

#0 0x000000000070c3cb in lh_retrieve() 
#1 0x000000000070db4b in int_thread_get_item() 
#2 0x000000000070eb6a in ERR_get_state() 
#3 0x000000000070f509 in ERR_set_mark() 
#4 0x000000000077bce0 in engine_table_select() 
#5 0x000000000070f829 in EVP_DigestInit_ex() 
#6 0x00000000006f39dd in HMAC_Init_ex() 
#7 0x00000000006f3ed1 in HMAC() 
#8 0x0000000000528bee in oauth_sign_hmac_sha1_raw (
    m=0x7fe88c1"<one secret url >"..., ml=366, 
    k=0x7fe88c03a150 "anonymous&nhjLEo8rcuvaqyL2ippxfAD2", kl=34) 
    at ./src/liboauth/hash5.c:314 
#9 0x0000000000527b0d in oauth_sign_array2_process (argcp=0x7fe892ffcb34, 
    argvp=0x7fe892ffcb38, postargs=<value optimized out>, method=OA_HMAC, 
    http_method=<value optimized out>, c_key=<value optimized out>, 
    c_secret=0x27b2230 "anonymous", 
    t_key=0x27b2710 "<token key>", 
    t_secret=0x2778e50 "<token secret>") 
    at ./src/liboauth/oauth.c:785 
#10 0x0000000000527c1e in oauth_sign_array2 (argcp=0x8688170, 
    argvp=0x7fe892ffc060, postargs=0x20, method=495, 
    http_method=0x20 <Address 0x20 out of bounds>, 
    c_key=0x101010101010101 <Address 0x101010101010101 out of bounds>, 
    c_secret=0x1 <Address 0x1 out of bounds>, 
    t_key=0x1 <Address 0x1 out of bounds>, 
    t_secret=0x1 <Address 0x1 out of bounds>) at ./src/liboauth/oauth.c:812 
#11 0x0000000000527d0d in oauth_sign_url2 (url=<value optimized out>, 
    postargs=0x7fe892ffcb88, method=OA_HMAC, http_method=0x7b89c7 "GET", 
    c_key=0x277cbc0 "anonymous", c_secret=0x27b2230 "anonymous", 
    t_key=0x1 <Address 0x1 out of bounds>, 

registres d'information me donnent

rax   0x1  1 
rbx   0x6e65637365643d72  7954873664093306226 
rcx   0x1ef 495 
rdx   0x20  32 
rsi   0x7fe892ffc060 140636875374688 
rdi   0x8688170  141066608 
rbp   0x270b480  0x270b480 
rsp   0x7fe892ffbff0 0x7fe892ffbff0 
r8    0x20  32 
r9    0x101010101010101  72340172838076673 
r10   0x416678707069324c  4712586484407415372 
r11   0x7fe89a15e0ae 140636994265262 
r12   0x7fe8700b8208 140636288942600 
r13   0x67ecf76fde2e0 1828279379944160 
r14   0x7fe892ffc060 140636875374688 
r15   0x70da00 7395840 
rip   0x70c3cb 0x70c3cb <lh_retrieve+139> 
eflags   0x10202 [ IF RF ] 
cs    0xe033 57395 
ss    0xe02b 57387 
ds    0x0  0 
es    0x0  0 
fs    0x0  0 
gs    0x0  0 
fctrl   0x37f 895 
fstat   0x0  0 
ftag   0xffff 65535 
fiseg   0x0  0 
fioff   0x6316b9 6493881 
foseg   0x7fe8 32744 
fooff   0x92ffc078  -1828732808 
fop   0x55c 1372 
mxcsr   0x1fa0 [ PE IM DM ZM OM UM PM ] 
+0

L'URL contient-elle vraiment 366 caractères? Cela semble un peu long. – asveikau

+0

La longueur de l'URL est de 200 caractères. –

+0

Ce n'est pas ce que dit le 2ème paramètre de 'oauth_sign_hmac_sha1_raw'. Je voudrais m'assurer que l'URL est valide, NUL s'est terminé, etc. – asveikau

Répondre

1

les gens votent pour fermer, mais personnellement, dans la bonne sorte d'humeur, je ne suis pas Occupe-toi d'un peu de travail de détective. :-)

par conversation avec Vivek l'instruction dans la formation de failles lh_retrieve était:

cmp %r13,0x10(%rbx) 

par-dessus rbx est 0x6e65637365643d72 qui ne ressemble pas du tout comme un pointeur valide ou avoir une ressemblance avec les autres pointeurs que nous voyons sur la pile. Quand je google certaines des fonctions sur la pile, cela ressemble à des routines OpenSSL pour générer des hachages, puis une routine regardant une structure de table de hachage ... Probablement du code, peut-être Vivek, a corrompu la structure de la table de hachage un tampon quelque part. Cela pourrait nous aider à nous montrer plus de code. :-)

+0

merci de donner votre temps précieux. –