Leaderboard

incerc sa-ti raspund eu a) cpu-ul in mare parte sta in idle, insa lumea nu vede asta in ziua de azi gaming inseamna gpu power, deci cpu-ul este doar pentru o.s. sa faca heavy lifting si sa lase gpu pt. gaming (sau hash rainbow table attacking hehe) c) de fapt nu prea conteaza cate core-uri daca ai banda mica sunt multe altele de luat in calcul (de exemplu metoda de calcul al cache-ului, sunt 3 tipuri pe procesoarele intel: unul este sa foloseasca linii intregi -cache lines-, altul este sa foloseasca una, iar un altul cel mai folosit este sa sacrifice intre aceste doua si sa comunice intre toate straturile de cache: L1, L2(,L3 pt. unii)). problema este ca in general (ca si Linux ca exemplu) se incearca sa se acopere standardizare si interoperabilitate si compatibilitate. asta inseamna sa sacrifici din cpu, insa vrei asta. ce nu vrei insa, este design gresit care nu face consum de resurse corect, iar in ultima vreme se tinde catre design foarte bun in aplicatii mari unde se incearca sa se stoarca de resurse pc-ul cat se poate de mult. pe Linux chiar este interesanta abordarea celor de la Firefox si Chrome (test: deschide n tab-uri si vezi resource consumption) unde chiar scurg ultima picatura de performanta fiindca stiu ca au kernel-ul bun pe dedesubt. alte aplicatii sunt cele de calcul masiv, cum sunt modele fizice, biologice si matematice unde este necesara computatie mare si putere mare de calcul. in principiu, pentru zi de zi, un cpu dual core este deja mai mult decat necesar, ce schimba acest lucru si cere, sunt interfetele foarte fancy (exemplu: Windows 7 aero & shit) care sacrifica performanta (a se citi: rupe cpu-ul prin kernel cu interrupt-uri pentru toate porcariile). asta este opinia mea; as fi tare curios sa iti aud parerea din UNIX

Se pare ca s-a uitat de tot de acest proiect foarte interesant. Am patchuit script-ul original realizand urmatorul changelog: fix client ^C, va trimite KILLME catre server acesta fiind sters din lista, de asemenea client-ul face SIGTERM fix server ^C, uneori ramanea blocat dupa ce afisa "[!] Forcibly closed." probabil in timpul incercarii log.close() introdus /KILLME in client, daca aceasta comanda este executata va fi anulat de server si nerecunoscut implementare server-side setsockopt pentru tuning-ul socket-urilor ce raman in stadiul TIME_WAIT, vezi: http://unixguide.net/network/socketfaq/4.5.shtml fix pentru KILLME, inainte conexiunea nu era cu adeverat inchisa, se foloseste acum SHUT_RDWR si .close() TODO: de testat comanda/comportamentul cu mai multi clienti -> server altele? DONE: de rectificat in client si server segterm-ul: try pe subprocess.Popen, la exceptie sa se faca .communicate() si conditiile pentru returncode etc. (prea tarziu acum) de testat daca la /KILLME clientul si conexiunea sa sunt flushed (nu ocupa socket cu server-ul aiurea => "self" DoS?), nu facea flush, odata la interrupt vedem ca ramanea conexiunea in FIN_WAIT, in acest moment clientul putea realiza o alta conexiune, intr-adevar, reinitializa socket-ul ce era pe FIN_WAIT insa nu este recomandat:$ netstat -antpul | grep 51337 tcp 0 0 127.0.1.1:51337 0.0.0.0:* LISTEN 12983/python tcp 0 0 127.0.0.1:38536 127.0.1.1:51337 [b][color=red]FIN_WAIT2[/color][/b] - tcp 1 0 127.0.1.1:51337 127.0.0.1:38536 CLOSE_WAITacum insa, este inchisa, ramane in TIME_WAIT insa nu pentru mult timp fix linia 434, trebuie identare la log.write("\n[!] Errors encountered.\n\n", MSGTOEXIT) sa cada sub if (prea tarziu acum) chat.py original: http://codepad.org/r9FCqTyC chat.py patches (old): patch0.1 :: http://codepad.org/Q6uJNAbH current chat.py patched (0.2): http://codepad.org/6mCZ9DO6diferenta (patch 0.1 - patch 0.2): http://pastie.org/private/0cthpd9lbvlbikmjfkqr7a Critici constructive?

Today, I’d like to describe a new technique we’ve come to call Reverse Clickjacking. The situation when this technique becomes useful typically arises when a user-controlled parameter is used when constructing a URL, and the parameter is not properly escaped. Consider the following code example. <script> var params = location.search.parseQuery(); var query = params["q"] || "Regina Spektor"; var script = document.createElement("SCRIPT"); script.src = "https://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=" + query + "&callback=handle_search_result"; document.body.appendChild(script); window.handle_search_result = function (json) {... }; window.delete_user_data = function () {... };</script> You can play around with it at - jsFiddle demo and modify it at Edit fiddle - JSFiddle. For a real-world example, take a look at Paul's blog post at @Paul_Axe : Two stories about XSS on Google. Notice there is a weakness in the code. The attacker-controlled "q" parameter is not URL-escaped when generating the search URL. OK, so how do we exploit this? We can use weakness to inject additional parameters into the URL. More specifically, we can override the callback parameter, and call a function of our choice. You'll notice that in the code snippet, we have a function called delete_user_data defined at the global level. We can call this using the JSONP callback to obtain a working exploit. Try this live at - jsFiddle demo. More commonly, we don't have any dangerous global functions, but instead we do have buttons that do interesting things. Consider this code. <div> <center> <h1>Welcome to this website.</h1> <button id=delete_user_data_button onclick="delete_user_data()">Delete all my data!</button> </center></div> Since button in question has a ID that is a valid JavaScript identifier, we can call it directly, e.g. - jsFiddle demo. Otherwise we can navigate through the DOM using firstElementChild and nextElementSibling, i.e. - jsFiddle demo. OK, so what can we do if the page containing the vulnerability does not contain any buttons or any interesting global functions? If we can find an interesting buttons on any other pages on the same domain, we can call them extending the technique described above. Suppose the vulnerable page is at - jsFiddle demo and the page with interesting button is at - jsFiddle demo. We construct our exploit as follows: <iframe src="http://fiddle.jshell.net/D5nZ7/1/show?q=elephants%26callback=parent.frames.btn_frame.document.body.firstElementChild.click%23" name="vuln_frame"></iframe><iframe src="http://fiddle.jshell.net/g5P9H/1/show" name="btn_frame"></iframe> See the code live at http://jsbin.com/vifuholi/1/edit. If either of the pages disallow embedding using X-Frame-Options, IFrames will not work, but that is not a fatal problem. Instead, we can open a pop-up window to another page we control and navigate the opener window to the button page. In the new pop-up, we wait for the main window to load the button page, and then navigate ourselves to the vulnerable page, which will do the clicking by accessing the button through window.opener. In previous versions of Chrome, pop-up windows that were blocked by the pop-up blocker were nevertheless executed, though their window were hidden from view. An more recent versions, in other browsers, we need a real user click to launch the initial pop-up. If you guys know a bypass, let us know in the comments. Code to do all this, along with clicking multiple buttons, is left as an exercise for the reader. Sursa: https://plus.google.com/u/0/+AleksandrDobkin-Google/posts/JMwA7Y3RYzV?cfem=1