Nytro

What is linux-gate.so.1? When you use the ldd utility on a reasonably recent Linux system you'll frequently see a reference to an ethereal entity known as linux-gate.so.1: ldd /bin/sh linux-gate.so.1 => (0xffffe000) libdl.so.2 => /lib/libdl.so.2 (0xb7fb2000) libc.so.6 => /lib/libc.so.6 (0xb7e7c000) /lib/ld-linux.so.2 (0xb7fba000) What's so strange about that? It's just a dynamically loaded library, right? Sort of, for sufficiently generous definitions of dynamically loaded library. The lack of file name in the output indicates that ldd was unable to locate a file by that name. Indeed, any attempt to find the corresponding file – whether manually or by software designed to automatically load and analyze such libraries – will be unsuccessful. From time to time this is a cause of befuddlement and frustration for users as they go searching for a non-existent system file. You can confidently tell users on this futile quest that there's not supposed to be a linux-gate.so.1 file present anywhere on the file system; it's a virtual DSO, a shared object exposed by the kernel at a fixed address in every process' memory: cat /proc/self/maps 08048000-0804c000 r-xp 00000000 08:03 7971106 /bin/cat 0804c000-0804d000 rwxp 00003000 08:03 7971106 /bin/cat 0804d000-0806e000 rwxp 0804d000 00:00 0 [heap] b7e88000-b7e89000 rwxp b7e88000 00:00 0 b7e89000-b7fb8000 r-xp 00000000 08:03 8856588 /lib/libc-2.3.5.so b7fb8000-b7fb9000 r-xp 0012e000 08:03 8856588 /lib/libc-2.3.5.so b7fb9000-b7fbc000 rwxp 0012f000 08:03 8856588 /lib/libc-2.3.5.so b7fbc000-b7fbe000 rwxp b7fbc000 00:00 0 b7fc2000-b7fd9000 r-xp 00000000 08:03 8856915 /lib/ld-2.3.5.so b7fd9000-b7fdb000 rwxp 00016000 08:03 8856915 /lib/ld-2.3.5.so bfac3000-bfad9000 rw-p bfac3000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Here cat prints its own memory map. The line marked [vdso] is the linux-gate.so.1 object in that process, a single memory page mapped at address ffffe000. A program can determine the location of the shared object in memory by examining an AT_SYSINFO entry in the ELF auxiliary vector. The auxiliary vector (auxv) is an array of pointers passed to new processes in the same way program arguments (argv) and environment variables (envp) are. The sample output above come from an x86 box where processes live in plain old 32-bit address spaces divided into pages of 4096 bytes, making ffffe000 the penultimate page. The very last page is reserved to catch accesses through invalid pointers, e.g. dereferencing a decremented NULL pointer or a MAP_FAILED pointer returned from mmap. I should note here that while linux-gate.so.1 is always mapped at this fixed location on that machine, the address used can differ between systems and even be randomly chosen per process as a security measure. On a system that does the latter, getting to the object is somewhat trickier and the following demonstration will not work. When all processes share the same object at the same location it's easy to extract a copy of it if we want to take a closer look at it. For example, we can simply ask dd to dump the page from its own memory (carefully choosing an output name different from linux-gate.so.1 to avoid creating a file that's not supposed to exist): dd if=/proc/self/mem of=linux-gate.dso bs=4096 skip=1048574 count=1 1+0 records in 1+0 records out We skip 1048574 because there are 220 = 1048576 pages in total and we want to extract the next to last page. The result looks like any other shared ELF object file: file -b linux-gate.dso ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped objdump -T linux-gate.dso linux-gate.dso: file format elf32-i386 DYNAMIC SYMBOL TABLE: ffffe400 l d .text 00000000 ffffe460 l d .eh_frame_hdr 00000000 ffffe484 l d .eh_frame 00000000 ffffe608 l d .useless 00000000 ffffe400 g DF .text 00000014 LINUX_2.5 __kernel_vsyscall 00000000 g DO *ABS* 00000000 LINUX_2.5 LINUX_2.5 ffffe440 g DF .text 00000007 LINUX_2.5 __kernel_rt_sigreturn ffffe420 g DF .text 00000008 LINUX_2.5 __kernel_sigreturn These symbols are entry points for the rt_sigreturn/sigreturn functions and for making virtual system calls. On the x86 platform linux-gate.so.1 was initially called linux-vsyscall.so.1, but this was changed during development to get a common name accurately reflecting its purpose across platforms: to act as a gateway between user and kernel space. Not all platforms need virtual syscalls, but they must be fairly important for x86 to warrant this elaborate mechanism. Traditionally, x86 system calls have been done with interrupts. You may remember that the way to request operating system functions was via interrupt 33 (21h) back in the bad old MS-DOS days. Windows system calls are buried beneath layers of user-mode APIs, but at some point they too boil down to int 0x2e. Similarly, syscall implementations in Linux and other *nix kernels have been using int 0x80. It turns out, though, that system calls invoked via interrupts are remarkably slow on the more recent members of the x86 processor family. An int 0x80 system call can be as much as an order of magnitude slower on a 2 GHz Pentium 4 than on an 850 MHz Pentium III. The impact on performance resulting from this could easily be significant, at least for applications that do a lot of system calls. Intel recognized this problem early on and introduced a more efficient system call interface in the form of sysenter and sysexit instructions. This fast system call feature first appeared in the Pentium Pro processor, but due to hardware bugs it's actually broken in most of the early CPUs. That's why you may see claims that sysenter was introduced with Pentium II or even Pentium III. The hardware problems also help explain why it took quite some time before operating systems started supporting fast system calls. If we ignore earlier experimental patches, Linux support for sysenter appeared in December 2002 during kernel 2.5 development. That's ten years after the instruction was defined! Microsoft started using sysenter only slightly earlier, in Windows XP. You can find out if your Linux machine is using the sysenter instruction for system calls by disassembling __kernel_vsyscall: objdump -d --start-address=0xffffe400 --stop-address=0xffffe414 linux-gate.dso linux-gate.dso: file format elf32-i386 Disassembly of section .text: ffffe400 <__kernel_vsyscall>: ffffe400: 51 push %ecx ffffe401: 52 push %edx ffffe402: 55 push %ebp ffffe403: 89 e5 mov %esp,%ebp ffffe405: 0f 34 sysenter ffffe407: 90 nop ffffe408: 90 nop ffffe409: 90 nop ffffe40a: 90 nop ffffe40b: 90 nop ffffe40c: 90 nop ffffe40d: 90 nop ffffe40e: eb f3 jmp ffffe403 <__kernel_vsyscall+0x3> ffffe410: 5d pop %ebp ffffe411: 5a pop %edx ffffe412: 59 pop %ecx ffffe413: c3 ret The preferred way of invoking a system call is determined by the kernel at boot time, and evidently this box uses sysenter. On an older machine you may see int 0x80 being used instead. In case you are struggling to make sense of that jump (like I was the first time I saw it) you might be interested to learn that it's there because Linus Torvalds is a disgusting pig and proud of it. (It's a trick to handle restarting of system calls with six parameters). Sursa: What is linux-gate.so.1?

[h=1]The TTY demystified[/h]The TTY subsystem is central to the design of Linux, and UNIX in general. Unfortunately, its importance is often overlooked, and it is difficult to find good introductory articles about it. I believe that a basic understanding of TTYs in Linux is essential for the developer and the advanced user. Beware, though: What you are about to see is not particularly elegant. In fact, the TTY subsystem — while quite functional from a user's point of view — is a twisty little mess of special cases. To understand how this came to be, we have to go back in time. [h=2]History[/h] In 1869, the stock ticker was invented. It was an electro-mechanical machine consisting of a typewriter, a long pair of wires and a ticker tape printer, and its purpose was to distribute stock prices over long distances in realtime. This concept gradually evolved into the faster, ASCII-based teletype. Teletypes were once connected across the world in a large network, called Telex, which was used for transferring commercial telegrams, but the teletypes weren't connected to any computers yet. Meanwhile, however, the computers — still quite large and primitive, but able to multitask — were becoming powerful enough to be able to interact with users in realtime. When the command line eventually replaced the old batch processing model, teletypes were used as input and output devices, because they were readily available on the market. There was a plethora of teletype models around, all slightly different, so some kind of software compatibility layer was called for. In the UNIX world, the approach was to let the operating system kernel handle all the low-level details, such as word length, baud rate, flow control, parity, control codes for rudimentary line editing and so on. Fancy cursor movements, colour output and other advanced features made possible in the late 1970s by solid state video terminals such as the VT-100, were left to the applications. In present time, we find ourselves in a world where physical teletypes and video terminals are practically extinct. Unless you visit a museum or a hardware enthusiast, all the TTYs you're likely to see will be emulated video terminals — software simulations of the real thing. But as we shall see, the legacy from the old cast-iron beasts is still lurking beneath the surface. Tutorial: http://www.linusakesson.net/programming/tty/index.php

Aia e altceva Rambo. Tot o sa arate urat, chiar daca nu mai iese din chenar si e doar "taiata".

Si pe mine parca ma racaia la ochi

Sa nu incadram totusi "Directory Listing" la capitolul ShowOff...

[h=2]Attackers Pounce on Zero-Day Java Exploit[/h]Attackers have seized upon a previously unknown security hole in Oracle’s ubiquitous Java software to break into vulnerable systems. So far, the attacks exploiting this weakness have been targeted and not widespread, but it appears that the exploit code is now public and is being folded into more widely-available attack tools such as Metasploit and exploit kits like BlackHole. News of the vulnerability surfaced late last week in a somewhat sparse blog post by FireEye, which said the exploit seemed to work against the latest version of Java 7, which is version 1.7, Update 6. This morning, researchers Andre’ M. DiMino & Mila Parkour published additional details on the targeted attacks seen so far, confirming that the zero-day affects Java 7 Update 0 through 6, but does not appear to impact Java 6 and below. Initial reports indicated that the exploit code worked against all versions of Internet Explorer, Firefox and Opera, but did not work against Google Chrome. But according to Rapid 7, there is a Metasploit module in development that successfully deploys this exploit against Chrome (on at least Windows XP). Also, there are indications that this exploit will soon be rolled into the BlackHole exploit kit. Contacted via instant message, the curator of the widely-used commercial attack tool confirmed that the now-public exploit code worked nicely, and said he planned to incorporate it into BlackHole as early as today. “The price of such an exploit if it were sold privately would be about $100,000,” wrote Paunch, the nickname used by the BlackHole author. Oracle has moved Java to a quarterly patch cycle, and its next update is not scheduled until October. In the meantime, it’s a good idea to either unplug Java from your browser or uninstall it from your computer completely. Windows users can find out if they have Java installed and which version by visiting java.com and clicking the “Do I have Java? link. Mac users can use the Software Update feature to check for any available Java updates. If you primarily use Java because some Web site, or program you have on your system — such as OpenOffice or Freemind — requires it, you can still dramatically reduce the risk from Java attacks just by disabling the plugin in your Web browser. In this case, I would suggest a two-browser approach. If you normally browse the Web with Firefox, for example, consider disabling the Java plugin in Firefox, and then using an alternative browser (Chrome, IE9, Safari, etc.) with Java enabled to browse only the site that requires it. For browser-specific instructions on disabling Java, click here. If you must use Java, security experts are prepping an unofficial patch for the program that should blunt this vulnerability, but it is being offered on a per-request basis at this point. A number of experts I know and respect have vouched for the integrity of this patch, but installing third-party patches should not be done lightly. Note that regressing to the latest version of Java 6 (Java/JRE 6 Update 34) is certainly an option, but not a very good one either. If you do not need Java, get rid of it, and if you do need it for specific applications or sites, limit your use of Java to those sites and applications, using a secondary browser for that purpose. Sursa: Attackers Pounce on Zero-Day Java Exploit — Krebs on Security

Chiar eram curios cat de complexe sunt "Anti"-urile astea ale lor... Edit: Se da kill la process Cam trist, toti antivirusii cam au self-defense si hook-uri pe OpeProcess/TerminateProcess, deci nu prea vor merge aceste "Anti-uri".

YAJDE = Yet Another Java Driveby Explit...

In sfarsit un POC!

Da, ce imaginatie bogata...

Stergeti si voi executabilele, nu aveti nevoie de ele, in niciun caz nu le executati. Daca tutorialul e ".exe", mutam topicul la gunoi.

La Costinesti pizza pizde cazare hotel femei cluburi shaorma in Costinesti

La Hotel Napoca e inchiriat in perioada respectiva si nu e indeajuns de mare. Asa parca zicea asta micu.

Da, e o idee, pare ok. Ar mai fi Crystal Pallace Ballrooms, dar cam prea mari si prea scump probabil. Bucuresteni, ceva sugestii in privinta locului?

Apasati si voi F2.

In primul rand, ce locatie ati sugera, votati. Apoi, daca aveti si alte sugestii, despre cum "sa fie", sunt binevenite. PS: a se vedea Blackhat si Defcon. Eu tot incerc sa dau de Andrewboy, dar nu prea reusesc.

Da ba, nu puteti sa va miscati curu...

Registrant Name:Matei Bogdan Registrant Organization:N/A Registrant Street1:Str. Constructorului, Nr. 8 Registrant City: Petrosani Registrant State/Province:Hunedoara Registrant Postal Code:332029 Registrant Country:RO Registrant Phone:+40.0732934042 Registrant Email: bogdanus_16_mihay@yahoo.com

Ban permanent si se muta la gunoi. La munca milogilor.

Nu vad nicio vulnerabilitate, ci doar un link. Vulnerabilitate RST: https://rstcenter.com/forum/admincp/index.php ? Se muta la gunoi.

Vad doar un link. Se muta la gunoi.

Oracle Abandoning MySQL Developers? To run you through the origin of MySQL, it is one of the most popular databases used by developers across the world. Sunday, August 19, 2012: Though there is no open announcement about it, but it’s getting almost clear that the company has all plans to close up the open source software, thereby abandoning the MySQL community. Stamping the move was the recent discovery, where the developers realised that the big fixes released for MySQL did not have any test cases to assure developers that the problem had actually been fixed. This is making the developers unsettled and confused about how Oracle defines open or closed software. And these developers are not shying away from openly talking about the problem in almost every platform. To run you through the origin of MySQL, it is one of the most popular databases used by developers across the world. It landed with Oracle, when it acquired Sun Microsystems in 2010. According to a post in MariaDB, MySQL has used a testing framework called mysql-test since 1999. Over the past years, tests have been built for new features and regression tests that guarantee that a bug fix is permanent. Developers such as those from Facebook and Twitter rely on the testing framework. At Twitter, MySQL serves as the “persistent storage technology behind most Twitter data: the interest graph, timelines, user data and the Tweets themselves.” Moreover, it is being reported that Oracle has removed the revision history for MySQL. This means that developers cannot know the set of changes made to the software, leaving them guessing what was changed when and by who. Kalpana Sharma, EFYTIMES News Network Sursa: http://news.efytimes.com/e1/89071/Oracle-Abandoning-MySQL-Developers

Nu, asa stiam si eu, dar am cautat mai mult de o pagina de "documentatie", si nu e chiar asa. In plus, am tot vazut zeci de pareri care se contrazic, iar diferenta in primul rand consta in modul in care se folosesc. Apoi, modul de implementare este total diferit, mai ales in functie de sistemele de operare. Pe Windows de exemplu, se pot folosi sectiuni critice in loc de mutexi, si e de preferat asta, deoarece sectiunile critice sunt implementate user-land, iar mutexul este un obiect global, inter-process, gestionat de kernel, iar aceste sysenter-uri in kernel sunt mai consumatoare de timp. Pe Linux la fel, lucrurile stau putin diferit, dar nu pot sa iti spun cu certitudine cum, deoarece am citit mai multe pareri si se contrazic, unele afirmand ca semafoarele sunt implementate user-land, ceea ce mi se pare o prostie din moment ce exista explicit syscall-uri special pentru lucrul cu semafoare, iar altii spuneau ca mutex-ul chiar este construit pe baza de semafor, in timp ce altii afirmau ca nu au nicio legatura, dar ca mutex-ul este implementat userland. Cand ajung la munca cred ca fac un mic "benchmark test".

Iar limbajul de asamblare poate sa difere: x86, ARM, powerpc... Cross compiling.