Nytro

E o porcarie sa pui "Hacked by Vasile", nu ii pasa nimanui si nu incanta pe nimeni. Daca ai obtinut acces, puteai sa arati asta, nu sa dai cu mucii in fasole si sa pui un cacat de mesaj acolo. Nu-i nimic, speram sa te schimbi pe viitor si sa intelegi ce inseamna "penibil". Sper ca nu te astepti la prea multe laude pentru aceasta "isprava"...

[h=2]Critical Security Fixes from Adobe, Microsoft[/h]Adobe and Microsoft each issued security updates today to fix critical vulnerabilities in their software. Adobe’s fixes include a patch for a Flash Player flaw that is actively being exploited to break into Windows computers. Microsoft’s Patch Tuesday release includes nine patch bundles — more than half of them rated critical — addressing at least 27 security holes in Windows and related software. The most pressing of the updates Adobe released today is the Flash Player patch, which fixes a critical flaw (CVE-2012-1535) in the ubiquitous media player software. Adobe says there are reports that the vulnerability is being exploited in the wild in limited targeted attacks, distributed through a malicious Microsoft Word document. The exploit targets the ActiveX version of Flash Player for Internet Explorer on Windows. Nevertheless, the underlying vulnerability being targeted exists in Windows, Mac and Linux versions of the software. Windows and Mac users can grab the latest version (v. 11.3.300.271) via the Flash Player download center. Be sure to uncheck the “free” software scans that Adobe loves to bundle with updates, such as McAfee‘s obnoxious Security Scan Plus, if you don’t want it. Linux users should update to v. 11.2.202.238, and Chrome users want to be at v. 11.3.330.270 (normally Chrome auto-updates Flash, but recently it’s been sluggish to do so: my Chrome installation is still at v. 11.3.31.225. I will update this post in a bit with the direct links to the Flash Player downloads. Adobe also pushed out a new version (v. 10.1.4) of Adobe Acrobat and Reader that corrects at least 20 distinct security vulnerabilities in Windows and Mac versions of these products. Windows users can grab the latest update from this link, and Mac users from here. Those looking for links to Adobe Acrobat updates and support for older versions of Reader should check the advisory that the company issued today for more information. In addition, Adobe released an update that fixes at least five critical flaws in Windows and Mac versions of its Shockwave Player software. If you have this program installed, update it. If not, forget about this patch, as you probably don’t need the software. The latest version is Shockwave Player 11.6.6.636 and is available via this link. At the top of the heap of security updates that Microsoft released today is MS12-060, which fixes a vulnerability in Microsoft Office that is already being exploited in the wild. Other high-priority updates from Redmond include a patch for a flaw in the Remote Administration protocol of Windows networking, and an Internet Explorer update that fixes two security holes. More information on the Windows patches is available from Microsoft’s Security Response Center and from Qualys. Microsoft patches are available through Windows Update or Automatic Update. As usual, please leave a note in the comments section if you experience problems applying any of these updates. Sursa: Critical Security Fixes from Adobe, Microsoft — Krebs on Security

Ce ma uimeste e ca prezentarea initiala de la Blackhat a fost facuta de catre... o femeie! Joanna Rutkowska E bine gandita ideea, dar ar fi cam dificil de exploatat.

Linux kernel poll. Daca nu aveti ce face, si sunteti pasionati de Linux/kernel: http://www.linuxjournal.com/content/linux-kernel-poll

The Mystery of the Encrypted Gauss Payload GReAT Kaspersky Lab Expert Posted August 14, 13:00 GMT Tags: Data Encryption, Cyber espionage, Gauss There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs? Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload. The containers Infected USB sticks have two files that contain several encrypted sections. Named “System32.dat” and “System32.bin”, they are 32-bit and 64-bit versions of the same code. These files are loaded from infected drives using the well-known LNK exploit introduced by Stuxnet. Their primary goal is to extract a lot of information about the victim system and write it back to a file on the drive named “.thumbs.db”. Several known versions of the files contain three encrypted sections (one code section, two data sections). The decryption key for these sections is generated dynamically and depends on the features of the victim system, preventing anyone except the designated target(s) from extracting the contents of the sections. By the way, the 64-bit version of the module has some debug information left in it. The module contains debug assertion strings and names of the modules: .\loader.cpp NULL != encSection Path NULL != pathVar && curPos < pathVarSize NULL != progFilesDirs && curPos < progFilesDirsSize NULL != isExpected NULL != key (NULL != result) && (NULL !=str1) && (NULL != str2) .\encryption_funcs.cpp The data The mysterious encrypted data is stored in three sections: The files also contain an encrypted resource “100” that seems to be the actual payload, given the relatively small size of the encrypted sections. It is most likely that the section “.exsdat” contains the code for decrypting the resource and executing its contents. The algorithm The code that decrypts the sections is very complex compared to any regular routine we usually find in malware. Here is a brief description of the algorithm: Validation 1. Make a list of all entries from GetEnvironmentPathW(“Path”), split by separator “;” 2. Append the list with all entries returned by FindFirstFileW / FindNextFileW by mask “%PROGRAMFILES%\*”, where cFileName[0] > 0x007A (UNICODE ‘z’) Note: in essence, this means the specific program which is installed in “%PROGRAMFILES%” has a name which starts either with a special char such as “~”, as in our example, or uses an UNICODE special char table, such as Arabic or Hebrew, where all chars are higher than 0x007A. 3. Make all possible pairs from the entries of the resulting list. 4. For each pair, append the first hard-coded 16-byte salt and calculate MD5 hash. Example of the string pair, second string starting from “~dir” and first salt 5. Calculate MD5 hash from the hash ( i.e. hash = md5(hash) ), 10000 times. 6. Compare if the MD5 hash matches the hard-coded value. If not, then exit. Decryption The sections are decrypted in the following order: .exsdat, .exrdat, .exdat 1. Use the PATH/PROGRAMFILES pair that was used to generate the expected MD5 hash in the validation code above. 2. Append the pair with the second hard-coded 16-byte salt and bytes 0x15, 0x00 Example of the string pair, second string starting from “~dir” and first salt 3. Calculate MD5 hash from the resulting buffer. 4. Calculate MD5 hash from the hash ( i.e. hash = md5(hash) ), 10000 times. 5. Derive the RC4 key from the resulting hash using WinAPI’s CryptDeriveKey(hProv, CALG_RC4, hBaseData, 0, &hKey). 6. Decrypt the section (RC4), treating its first DWORD as the length of the buffer to decrypt and encrypted buffer starting at offset 4 of the section. 7. Compare DWORDs in the decrypted buffer at positions 0 or 7 with magic value “0x20332137”. Proceed only if any of the DWORDs match. 8. Increase the last WORD in the pair+salt buffer (the one initially set to 0x0015) by 1. 9. Decrypt another section, goto 3. After all the sections are decrypted: call the function at the beginning of the .exsdat section. Sample data for validating the algorithm: The string pair is created by concatenating the strings. The strings and the salt buffer are not separated by any character. Sample test Strings, Unicode (without quotes): “C:\Documents and Settings\john\Local Settings\Application Data\Google\Chrome\Application” “~dir1” First salt, hex dump : 97 48 6C AA 22 5F E8 77 C0 35 CC 03 73 23 6D 51 MD5 at validation step 6: 76405ce7f4e75e352c1cd4d9aeb6be41 Second salt, hex dump : BB 49 4E 77 F9 25 EE C0 3B 89 FC ED C2 22 4A 21 MD5 at decryption step 5: 00916031b3e9513044436ee42b6aa273 Join the quest We have tried millions of combinations of known names in %PROGRAMFILES% and Path, without success. The check for the first character of the folder in %PROGRAMFILES% indicates that the attackers are looking for a very specific program with the name written in an extended character set, such as Arabic or Hebrew, or one that starts with a special symbol such as “~”. Of course, it is obvious that it is not feasible to break the encryption with a simple brute-force attack. We are asking anyone interested in breaking the code and figuring out the mysterious payload to join us. The resource section is big enough to contain a Stuxnet-like SCADA targeted attack code and all the precautions used by the authors indicate that the target is indeed high profile. We are providing the first 32 bytes of encrypted data and hashes from known variants of the modules. If you are a world class cryptographer or if you can help us with decrypting them, please contact us by e-mail: theflame@kaspersky.com. Source data We are providing up to 32 bytes from the beginning of each encrypted section, skipping the DWORD that contains the length of the encrypted buffer. Please contact us by e-mail theflame@kaspersky.com if you need more encrypted data. [TABLE=class: fullbrd, width: 100%] [TR] [TD] Sample [/TD] [TD] 56e4fb972828fafbbdc11158a1b5fa72 [/TD] [/TR] [TR] [TD] Salt 1 [/TD] [TD] 97 48 6C AA 22 5F E8 77 C0 35 CC 03 73 23 6D 51[/TD] [/TR] [TR] [TD]Reference MD5[/TD] [TD]758EA09A147DCBCAD6BD558BE30774DE [/TD] [/TR] [TR] [TD] Salt 2 [/TD] [TD]BB 49 4E 77 F9 25 EE C0 3B 89 FC ED C2 22 4A 21 [/TD] [/TR] [TR] [TD] Exsdat [/TD] [TD]4C CC BA E2 E0 BA 2E 44 C7 60 17 9A 72 F4 2F 27 DD FD DB 11 03 94 E3 4B 0A 16 66 F3 36 97 6C D8[/TD] [/TR] [TR] [TD]Exrdat[/TD] [TD]C9 27 BE 67 4D 3B 39 36 AB 14 44 32 88 60 7A 64 B0 92 9B 3A A1 5B C5 21 A7 6E 09 0C F8 71 84 87[/TD] [/TR] [TR] [TD] Exdat[/TD] [TD]B8 EB 6D 61 2B 4F 70 65 75 A2 1C 03 1C DF 26 2F[/TD] [/TR] [/TABLE] [TABLE=class: fullbrd, width: 100%] [TR] [TD] Sample [/TD] [TD] 695056ffacef1fdaa326d7c8bb0f88ba [/TD] [/TR] [TR] [TD] Salt 1 [/TD] [TD]6E E3 47 2C 06 A5 C8 59 BD 16 42 D1 D4 F5 BB 3E[/TD] [/TR] [TR] [TD]Reference MD5[/TD] [TD]EB2F172398261ED94C8D05216650919B[/TD] [/TR] [TR] [TD] Salt 2 [/TD] [TD]8F 42 B5 87 E8 9A B2 32 C8 1C 1A EC B5 2D 55 19[/TD] [/TR] [TR] [TD] Exsdat [/TD] [TD]CE 31 D0 5D 7D CB 57 9A 83 06 09 8D 42 2B 44 34 24 13 B2 39 22 48 8F F3 76 E5 9C DA 87 8F BC 42[/TD] [/TR] [TR] [TD]Exrdat[/TD] [TD]50 1F F8 BA 18 1B 3E 36 23 9D 95 DC 5A 07 E4 EC 76 38 78 79 BA 84 A5 4E 24 BA 0E 27 94 63 F7 3D[/TD] [/TR] [TR] [TD] Exdat[/TD] [TD]9D 5B B8 3B B2 17 00 DC 76 81 1D 4E 54 80 9B 31[/TD] [/TR] [/TABLE] [TABLE=class: fullbrd, width: 100%] [TR] [TD] Sample [/TD] [TD] 089d45e4c3bb60388211aa669deab26a [/TD] [/TR] [TR] [TD] Salt 1 [/TD] [TD]0E A5 01 D1 24 71 CD CD 0E 9E AC 6E 48 5A F9 32[/TD] [/TR] [TR] [TD]Reference MD5[/TD] [TD]52DD4D6B792D84C422E6A08E4272ACB8[/TD] [/TR] [TR] [TD] Salt 2 [/TD] [TD]38 F9 A6 5B 82 08 E7 61 1D 10 73 53 50 BC B4 F0[/TD] [/TR] [TR] [TD] Exsdat [/TD] [TD]D3 CA 9D 9F 87 FB 25 43 7E C6 57 7C D9 06 10 8D D2 5B B2 88 18 6E FD B4 C4 30 12 2E 1E EC E0 64[/TD] [/TR] [TR] [TD]Exrdat[/TD] [TD]B4 43 8F B8 0A 67 7D 88 C1 CD F3 E8 D9 61 1B E9 5A 8A 41 16 8B 8A 18 AD 25 5A 81 87 8F 8D 1A 40[/TD] [/TR] [TR] [TD] Exdat[/TD] [TD]F6 C9 81 C9 86 27 16 0C B7 33 93 AB 3E 71 5B E2[/TD] [/TR] [/TABLE] [TABLE=class: fullbrd, width: 100%] [TR] [TD] Sample [/TD] [TD] 8d90e3c68030fbb91ad5b920d5e17b32 [/TD] [/TR] [TR] [TD] Salt 1 [/TD] [TD]C3 23 4D 51 5D 52 A5 8E 81 46 FA 8A 6D 93 DF 7D[/TD] [/TR] [TR] [TD]Reference MD5[/TD] [TD]53B3FAEA53CC1B90AA2C5FCF831EF9E2[/TD] [/TR] [TR] [TD] Salt 2 [/TD] [TD]21 9D 04 35 7B 96 74 53 B0 9C CD 7F 2F E6 63 AA[/TD] [/TR] [TR] [TD] Exsdat [/TD] [TD]AB 01 6A 8E 42 F0 F2 92 1D F1 4A 42 01 63 72 78 D6 F7 A5 0C 54 37 21 2C B8 59 6A D0 7E 68 19 2D[/TD] [/TR] [TR] [TD]Exrdat[/TD] [TD]6C 2D D7 E4 F6 08 15 C0 69 D9 9E FF EA 68 63 4F 56 59 DA 28 E5 2E A1 EF 21 FB F9 2B C2 BC E7 CE[/TD] [/TR] [TR] [TD] Exdat[/TD] [TD]55 A7 F3 93 E0 AF 5B 7E 17 22 7E 82 8A 6F 25 21 3D 64 D7 E8[/TD] [/TR] [/TABLE] Sursa: The Mystery of the Encrypted Gauss Payload - Securelist

The C build process In this article we look at the C build process – that is, how we get from C source files to executable code, programmed on the target. It wasn’t so long ago this was common knowledge (the halcyon days of the hand-crafted make file!) but modern IDEs are making this knowledge ever-more arcane. Compilation The first stage of the build process is compilation. The compiler is responsible for allocating memory for definitions (static and automatic) and generating opcodes from program statements. A relocatable object file (.o) is produced. The assembler also produces .o files from assembly-language source. The compiler works with one translation unit at a time. A translation unit is a .c file that has passed through the pre-processor. The compiler and assembler create relocatable object files (.o) A Librarian facility may be used to take the object files and combine them into a library file. Compilation stages Compilation is a multi-stage process; each stage working with the output of the previous. The Compiler itself is normally broken down into three parts: The front end, responsible for parsing the source code The middle end, responsible for optimisation The back end, responsible for code generation Front End Processing: Pre-processing The pre-processor parses the source code file and evaluates pre-processor directives (starting with a #) – for example #define. A typical function of the pre-processor is to#include function / type declarations from header files. The input to the pre-processor is known as a pre-processed translation unit; the output from the pre-processor is a post-processed translation unit. Whitespace removal C ignores whitespace so the first stage of processing the translation unit is to strip out all whitespace. Tokenising A C program is made up of tokens. A token may be a keyword (for example ‘while’) an operator (for example, ‘*’) an identifier; a variable name a literal (for example, 10 or “my string”) a comment (which is discarded at this point) Syntax analysis Syntax analysis ensures that tokens are organised in the correct way, according to the rules of the language. If not, the compiler will produce a syntax error at this point. The output of syntax analysis is a data structure known as a parse tree. Intermediate Representation The output from the compiler front end is a functionally equivalent program expressed in some machine-independent form known as an Intermediate Representation (IR). The IR program is generated from the parse tree. IR allows the compiler vendor to support multiple different languages (for example C and C++) on multiple targets without having n * m combinations of toolchain. There are several IRs in use, for example Gimple, used by GCC. IRs are typically in the form of an Abstract Syntax Tree (AST) or pseudo-code. Middle End Processing: Semantic analysis Semantic analysis adds further semantic information to the IR AST and performs checks on the logical structure of the program. The type and amount of semantic analysis performed varies from compiler to compiler but most modern compilers are able to detect potential problems such as unused variables, uninitialized variables, etc. Any problems found at this stage are normally presented as warnings, rather than errors. It is normally at this stage the program symbol table is constructed, and any debug information inserted. Optimisation Optimisation transforms the code into a functionally-equivalent, but smaller or faster form. Optimisation is usually a multi-level process. Common optimisations include inline expansion of functions, dead code removal, loop unrolling, register allocation, etc. Back End Processing: Code generation Code generation converts the optimised IR code structure into native opcodes for the target platform. Memory allocation The C compiler allocates memory for code and data in Sections. Each section contains a different type of information. Sections may be identified by name and/or with attributes that identify the type of information contained within. This attribute information is used by the Linker for locating sections in memory (see later). Code Opcodes generated by the compiler are stored in their own memory section, typically known as .code or .text Static data The static data region is actually subdivided into two further sections: one for uninitialized-definitions (int iVar1; ). one for initialised-definitions (int iVar2 = 10; ) So it would not be unexpected for the address of iVar1 and iVar2 to not be adjacent to each other in memory. The uninitialized-definitions’ section is commonly known as the .bss or ZI section. The initialised-definitions’ section is commonly known as the .data or RW section. Constants Constants may come in two forms: User-defined constant objects (for example const int c; ) Literals (‘magic numbers’, macro definitions or strings) The traditional C model places user-defined const objects in the .data section, along with non-const statics (so they may not be truly constant – this is why C disallows using constant integers to initialise arrays, for example) Literals are commonly placed in the .text / .code section. Most compilers will optimise numeric literals away and use their values directly where possible. Many modern C toolchains support a separate .const / .rodata section specifically for constant values. This section can be placed (in ROM) separate from the .data section. Strictly, this is a toolchain extension. Automatic variables The majority of variables are defined within functions and classed as automatic variables. This also includes parameters and any temporary-returned-object (TRO) from a non-void function. The default model in general programming is that the memory for these program objects is allocated from the stack. For parameters and TRO’s the memory is normally allocated by the calling function (by pushing values onto the stack), whereas for local objects, memory is allocated once the function is called. This key feature enables a function to call itself – recursion (though recursion is generally a bad idea in embedded programming as it may cause stack-overflow problems). In this model, automatic memory is reclaimed by popping the stack on function exit. It is important to note that the compiler does NOT create a .stack segment. Instead, opcodes are generated that access memory relative to some register, the Stack Pointer, which is configured at program start-up to point to the top of the stack segment (see below) However, on most modern microcontrollers, especially 32-bit RISC architectures, automatics are stored in scratch registers, where possible, rather than the stack. For example the ARM Architecture Procedure Call Standard (AAPCS) defines which CPU registers are used for function call arguments into, and results from, a function and local variables. Dynamic data Memory for dynamic objects is allocated from a section known as the Heap. As with the Stack, the Heap is not allocated by the compiler at compile time but by the Linker at link-time. Object files The compiler produces relocatable object files – .o files. The object file contains the compiled source code – opcodes and data sections. Note that the object file only contains the sections for static variables. At this stage, section locations are not fixed. The .o file is not (yet) executable because, although some items are set in concrete (for example: instruction opcodes, pc-relative addresses, “immediate” constants, etc.), static and global addresses are known only as offsets from the starts of their relevant sections. Also, addresses defined in other modules are not known at all, except by name. The object file contains two tables - Imports and Exports: Exports contains any extern identifiers defined within this translation unit (so no statics!) Imports contains any identifiers declared (and used) within the translation; but not defined within it. Note the identifier names are in name-mangled form. Linking The Linker combines the (compiled) object files into a single executable program. In order to do that it must perform a number of tasks. Symbol resolution The primary function of the Linker (from whence it derives its name) is to resolve references between object files – that is, to ensure each symbol defined by the program has a unique address. If any references remain unresolved, all specified library/archive (.a) files are searched and the appropriate modules are gathered in order to resolve those references. This is an iterative process. If, after this, the Linker still cannot resolve a symbol it will report an ‘unresolved reference’ error. Similarly, C specifies a ‘one-definition rule’ – that is, each symbol must have a unique and unambiguous address. If the Linker finds the same symbol defined in two object files it will report a ‘redefinition’ error (be careful, though – some older C compilers assume that the same symbol defined in two translation units must refer to the same object!) Section concatenation The Linker then concatenates like-named sections from the input object files. The combined sections (output sections) are usually given the same names as their input sections. Program addresses are adjusted to take account of the concatenation. Section location To be executable code and data sections must be located at absolute addresses in memory. Each section is given an absolute address in memory. This can be done on a section-by-section basis but more commonly sections are concatenated from some base address. Normally there is one base address in non-volatile memory for persistent sections (for example code) and one address in volatile memory for non-persistent sections (for example the Stack). Data initialisation On an embedded system any initialised data must be stored in non-volatile memory (Flash / ROM). On startup any non-const data must be copied to RAM. It is also very common to copy read-only sections like code to RAM to speed up execution (not shown in this example). In order to achieve this the Linker must create extra sections to enable copying from ROM to RAM. Each section that is to be initialized by copying is divided into two, one for the ROM part (the initialisation section) and one for the RAM part (the run-time location). The initialisation section generated by the Linker is commonly called a shadow data section – .sdata in our example (although it may have other names). If manual initialization is not used, the linker also arranges for the startup code to perform the initialization. The .bss section is also located in RAM but does not have a shadow copy in ROM. A shadow copy is unnecessary, since the .bss section contains only zeroes. This section can be initialised algorithmically as part of the startup code. Linker control The detailed operation of the linker can be controlled by invocation (command-line) options or by a Linker Control File (LCF). You may know this file by another name such as linker-script file, linker configuration file or even scatter-loading description file. The LCF file defines the physical memory layout (Flash/SRAM) and placement of the different program regions. LCF syntax is highly compiler-dependent, so each will have its own format; although the role performed by the LCF is largely the same in all cases. When an IDE is used, these options can usually be specified in a relatively friendly way. The IDE then generates the necessary script and invocation options. The most important thing to control is where the final memory sections are located. The hardware memory layout must obviously be respected – for most processors, certain things must be in specific places. Secondly, the LCF specifies the size and location of the Stack and Heap (if dynamic memory is used). It is common practice to locate the Stack and Heap with the Heap at the lower address in RAM and the Stack at a higher address to minimise the potential for the two areas overlapping (remember, the Heap grows up the memory and the Stack grows down) and corrupting each other at run-time. The linker configuration file shown above leads to a fairly typical memory layout shown here. .cstartup – the system boot code – is explicitly located at the start of Flash. .text and .rodata are located in Flash, since they need to be persistent .stack and .heap are located in RAM. .bss is located in RAM in this case but is (probably) empty at this point. It will be initialised to zero at start-up. The .data section is located in RAM (for run-time) but its initialisation section, .sdata, is in ROM. The Linker will perform checks to ensure that your code and data sections will fit into the designated regions of memory. The output from the locating process is a load file in a platform-independent format, commonly .ELF or .DWARF (although there are many others) The ELF file is also used by the debugger when performing source-code debugging. Loading ELF or DWARF are target-independent output file formats. In order to be loaded onto the target the ELF file must be converted into a native flash / PROM format (typically, .bin or .hex) Key points The compiler produces opcodes and data allocation from source code files to produce an object file. The compiler works on a single translation unit at a time. The linker concatenates object files and library files to create a program The linker is responsible for allocating stack and free store sections The linker operation is controlled by a configuration file, unique to the target system. Linked files must be translated to a target-dependent format for loading onto the target. Posted on June 29th, 2012 Sursa: Sticky Bits

[h=1]Mutex vs. Semaphores – Part 2: The Mutex[/h]Autor: nsc(at)acm.org. In Part 1 of this series we looked at the history of the binary and counting semaphore, and then went on to discuss some of the associated problem areas. In this posting I aim to show how a different RTOS construct, the mutex, may overcome some, if not all, of these weaknesses. To address the problems associated with semaphore, a new concept was developed during the late 1980’s. I have struggled to find it’s first clear definition, but the major use of the term mutex (another neologism based around MUTual EXclusion) appears to have been driven through the development of the common programming specification for UNIX based systems. In 1990 this was formalised by the IEEE as standard IEEE Std 1003.1 commonly known as POSIX. The mutex is similar to the principles of the binary semaphore with one significant difference: the principle of ownership. Ownership is the simple concept that when a task locks (acquires) a mutex only it can unlock (release) it. If a task tries to unlock a mutex it hasn’t locked (thus doesn’t own) then an error condition is encountered and, most importantly, the mutex is not unlocked. If the mutual exclusion object doesn’t have ownership then, irrelevant of what it is called, it is not a mutex. The concept of ownership enables mutex implementations to address the problems discussed in part 1: Accidental release Recursive deadlock Task-Death deadlock Priority inversion Semaphore as a signal Accidental Release As already stated, ownership stops accidental release of a mutex as a check is made on the release and an error is raised if current task is not owner. Recursive Deadlock Due to ownership, a mutex can support relocking of the same mutex by the owning task as long as it is released the same number of times. Priority Inversion With ownership this problem can be addressed using one of the following priority inheritance protocols: [basic] Priority Inheritance Protocol Priority Ceiling Protocol The Basic Priority Inheritance Protocol enables a low-priority task to inherit a higher-priorities task’s priority if this higher-priority task becomes blocked waiting on a mutex currently owned by the low-priority task. The low priority task can now run and unlock the mutex – at this point it is returned back to its original priority. The details of the Priority Inheritance Protocol and Priority Ceiling Protocol (a slight variant) will be covered in part 3 of this series. Death Detection If a task terminates for any reason, the RTOS can detect if that task current owns a mutex and signal waiting tasks of this condition. In terms of what happens to the waiting tasks, there are various models, but two doiminate: All tasks readied with error condition; Only one task readied; this task is responsible for ensuring integrity of critical region. When all tasks are readied, these tasks must then assume critical region is in an undefined state. In this model no task currently has ownership of the mutex. The mutex is in an undefined state (and cannot be locked) and must be reinitialized. When only one task is readied, ownership of the mutex is passed from the terminated task to the readied task. This task is now responsible for ensuring integrity of critical region, and can unlock the mutex as normal. Mutual Exclusion / Synchronisation Due to ownership a mutex cannot be used for synchronization due to lock/unlock pairing. This makes the code cleaner by not confusing the issues of mutual exclusion with synchronization. Caveat A specific Operating Systems mutex implementation may or may not support the following: Recursion Priority Inheritance Death Detection Review of some APIs It should be noted that many Real-Time Operating Systems (or more correctly Real-Time Kernels) do not support the concept of the mutex, only supporting the Counting Semaphore (e.g. MicroC/OS-II). [ CORRECTION: The later versions of uC/OS-II do support the mutex, only the original version did not]. In this section we shall briefly examine three different implementations. I have chosen these as they represent the broad spectum of APIs offered (Footnote 1): VxWorks Version 5.4 POSIX Threads (pThreads) – IEEE Std 1003.1, 2004 Edition Microsoft Windows Win32 – Not .NET VxWorks from Wind River Systems is among the leading commercial Real-Time Operating System used in embedded systems today. POSIX Threads is a widely supported standard, but has become more widely used due to the growth of the use of Embedded Linux. Finally Microsoft Window’s common programming API, Win32 is examined. Windows CE, targeted at embedded development, supports this API. However, before addressing the APIs in detail we need to introduce the concept of a Release Order Policy. In Dijkstra’s original work the concept of task priorities were not part of the problem domain. Therefore it was assumed that if more than one task was waiting on a held semaphore, when released the next task to acquire the semaphore would be chosen on a First-Come-First-Server (First-In-First-Out; FIFO) policy. However once tasks have priorities, the policy may be: FIFO – waiting tasks ordered by arrival time Priority – waiting tasks ordered by priority Undefined - implementation doesn’t specify VxWorks v5.4 VxWorks supports the Binary Semaphore, the Counting Semaphore and the Mutex (called the Mutual-Exclusion Semaphore in VxWorks terminology). They all support a common API for acquiring (semTake) and releasing (semGive) the particular semaphore. For all semaphore types, waiting tasks can be queued by priority or FIFO and can have a timeout specified. The Binary Semaphore has, as expected, no support for recursion or inheritance and the taker and giver do not have to be same task. Some additional points of interest are that there is no effect of releasing the semaphore again; It can be used as a signal (thus can be created empty); and supports the idea of a broadcast release (wake up all waiting tasks rather than just the first). The Counting Semaphore, as expected, is the same as the Binary Semaphore with ability to define an initial count. The Mutual-Exclusion Semaphore is the VxWorks mutex. Only the owning task may successfully call semGive. The VxWorks mutex also has the ability to support both priority inheritance (basic priority inheritance protocol) and deletion safety. POSIX POSIX is an acronym for Portable Operating System Interface (the X has no meaning). The current POSIX standard is formally defined by IEEE Std 1003.1, 2004 Edition. The mutex is part of the core POSIX Threads (pThreads) specification (historically referred to as IEEE Std 1003.1c-1995). POSIX also supports both semaphores and priority-inheritance mutexes as part of what are called Feature Groups. Support for these Feature Groups is optional, but when an implementation claims that a feature is provided, all of its constituent parts must be provided and must comply with this specification. There are two main Feature Groups of interest, the Realtime Group and Realtime Threads Groups. The semaphore is not part of the core standard but is supported as part of the Realtime Feature Group. The Realtime Semaphore is an implementation of the Counting semaphore. The default POSIX mutex is non-recursive , has no priority inheritance support or death detection. However, the Pthreads standard allows for non-portable extensions (as long as they are tagged with “-np”). A high proportion of programmers using POSIX threads are programming for Linux. Linux supports four different mutex types through non-portable extensions: Fast mutex – non-recursive and will deadlock [default] Error checking mutex – non-recursive but will report error Recursive mutex – as the name implies Adaptive mutex - extra fast for mutli-processor systems These are extreamly well covered by Chris Simmonds in his posting Mutex mutandis: understanding mutex types and attributes. Finally the Realtime Threads Feature Group adds mutex support for both priority inheritance and priority ceiling protocols. Win32 API Microsoft Window’s common API is referred to as Win32. This API supports three different primitives: Semaphore – The counting semaphore Critical Section - Mutex between threads in the same process; Recursive, no timeout, queuing order undefined Mutex – As per critical sections, but can be used by threads in different processes; Recursive, timeout, queuing order undefined The XP/Win32 mutex API does not support priority inheritance in application code, however the WinCE/Win32 API does! Win32 mutexes do have built-in death detection; if a thread terminates when holding a mutex, then that mutex is said to be abandoned. The mutex is released (with WAIT_ABANDONED error code) and a waiting thread will take ownership. Note that Critical sections do not have any form of death detection. Critical Sections have no timeout ability, whereas mutexes do. However Critical Sections support a separate function call TryEnterCriticalSection. A major weakness of the Win32 API is that the queuing model is undefined (i.e. neither Priority nor FIFO). According to Microsoft this is done to improve performance. So, what can we gather from this? First and foremost the term mutex is less well defined than the semaphore. Secondly,the actual implementations from RTOS to RTOS vary massively. I urge you to go back and look at your faviourite RTOS and work out what support, if any, you have for the mutex. I’d love to hear from people regarding mutual exclusion support (both semaphores and mutexes) for their RTOS of choice. If you’d like to contact me do so at nsc(at)acm.org. Finally, Part 3 will look at a couple of problems the mutex doesn’t solve, and how these can be overcome. As part of that it will review the Basic Priority Inheritance Protcol and the Prority Ceiling Protocol. At a later date I will also address the use of, and problems associted with, the semaphore being used for task synchronisation. ENDNOTES Please I do not want to get into the “that’s not a real-time OS” debate here – let’s save that for another day! A number of people pointed out that Michael Barr (former editor of Embedded Systems Programming, now president of Netrino) has a good article about the differences between mutexes & semaphores at the following location: Mutexes and Semaphores Demystified | Embedded Systems Experts. I urge you to read his posting as well. Apologies about not having the atom feed sorted – this should all be working now Posted on September 11th, 2009 Sursa: Sticky Bits

Mutex vs. Semaphores – Part 1: Semaphores Autor: nsc(at)acm.org. It never ceases to amaze me how often I see postings in newsgroups, etc. asking the difference between a semaphore and a mutex. Probably what baffles me more is that over 90% of the time the responses given are either incorrect or missing the key differences. The most often quoted response is that of the “The Toilet Example © Copyright 2005, Niclas Winquist” . This summarises the differences as: A mutex is really a semaphore with value 1 No, no and no again. Unfortunately this kind of talk leads to all sorts of confusion and misunderstanding (not to mention companies like Wind River Systems redefining a mutex as a “Mutual-Exclusion Semaphore” – now where is that wall to bang my head against?). Firstly we need to clarify some terms and this is best done by revisiting the roots of the semaphore. Back in 1965, Edsger Dijkstra, a Dutch computer scientist, introduced the concept of a binary semaphore into modern programming to address possible race conditions in concurrent programs. His very simple idea was to use a pair of function calls to the operating system to indicate entering and leaving a critical region. This was achieved through the acquisition and release of an operating system resource called a semaphore. In his original work, Dijkstra used the notation of P & V, from the Dutch words Prolagen (P), a neologism coming from To try and lower, and Verhogen (V) To raise, To increase. With this model the first task arriving at the P(S) [where S is the semaphore] call gains access to the critical region. If a context switch happens while that task is in the critical region, and another task also calls on P(S), then that second task (and any subsequent tasks) will be blocked from entering the critical region by being put in a waiting state by the operating system. At a later point the first task is rescheduled and calls V(S) to indicate it has left the critical region. The second task will now be allowed access to the critical region. A variant of Dijkstra’s semaphore was put forward by another Dutchman, Dr. Carel S. Scholten. In his proposal the semaphore can have an initial value (or count) greater than one. This enables building programs where more than one resource is being managed in a given critical region. For example, a counting semaphore could be used to manage the parking spaces in a robotic parking system. The initial count would be set to the initial free parking places. Each time a place is used the count is decremented. If the count reaches zero then the next task trying to acquire the semaphore would be blocked (i.e. it must wait until a parking space is available). Upon releasing the semaphore (A car leaving the parking system) the count is incremented by one. Scholten’s semaphore is referred to as the General or Counting Semaphore, Dijkstra’s being known as the Binary Semaphore. Pretty much all modern Real-Time Operating Systems (RTOS) support the semaphore. For the majority, the actual implementation is based around the counting semaphore concept. Programmers using these RTOSs may use an initial count of 1 (one) to approximate to the binary semaphore. One of the most notable exceptions is probably the leading commercial RTOS VxWorks from Wind River Systems. This has two separate APIs for semaphore creation, one for the Binary semaphore (semBCreate) and another for the Counting semaphore (semCCreate). Hopefully we now have a clear understanding of the difference between the binary semaphore and the counting semaphore. Before moving onto the mutex we need to understand the inherent dangers associated with using the semaphore. These include: Accidental release Recursive deadlock Task-Death deadlock Priority inversion Semaphore as a signal All these problems occur at run-time and can be very difficult to reproduce; making technical support very difficult. Accidental release This problem arises mainly due to a bug fix, product enhancement or cut-and-paste mistake. In this case, through a simple programming mistake, a semaphore isn’t correctly acquired but is then released. When the counting semaphore is being used as a binary semaphore (initial count of 1 – the most common case) this then allows two tasks into the critical region. Each time the buggy code is executed the count is increment and yet another task can enter. This is an inherent weakness of using the counting semaphore as a binary semaphore. Deadlock Deadlock occurs when tasks are blocked waiting on some condition that can never become true, e.g. waiting to acquire a semaphore that never becomes free. There are three possible deadlock situations associated with the semaphore: Recursive Deadlock Deadlock through Death Cyclic Deadlock (Deadly Embrace) Here we shall address the first two, but shall return to the cyclic deadlock in a later posting. Recursive Deadlock Recursive deadlock can occur if a task tries to lock a semaphore it has already locked. This can typically occur in libraries or recursive functions; for example, the simple locking of malloc being called twice within the framework of a library. An example of this appeared in the MySQL database bug reporting system: Bug #24745 InnoDB semaphore wait timeout/crash – deadlock waiting for itself Deadlock through Task Death What if a task that is holding a semaphore dies or is terminated? If you can’t detect this condition then all tasks waiting (or may wait in the future) will never acquire the semaphore and deadlock. To partially address this, it is common for the function call that acquires the semaphore to specify an optional timeout value. Priority Inversion The majority of RTOSs use a priority-driven pre-emptive scheduling scheme. In this scheme each task has its own assigned priority. The pre-emptive scheme ensures that a higher priority task will force a lower priority task to release the processor so it can run. This is a core concept to building real-time systems using an RTOS. Priority inversion is the case where a high priority task becomes blocked for an indefinite period by a low priority task. As an example: An embedded system contains an “information bus” Sequential access to the bus is protected with a semaphore. A bus management task runs frequently with a high priority to move certain kinds of data in and out of the information bus. A meteorological data gathering task runs as an infrequent, low priority task, using the information bus to publish its data. When publishing its data, it acquires the semaphore, writes to the bus, and release the semaphore. The system also contains a communications task which runs with medium priority. Very infrequently it is possible for an interrupt to occur that causes the (medium priority) communications task to be sch eduled while the (high priority) information bus task is blocked waiting for the (low priority) meteorological data task. In this case, the long-running communications task, having higher priority than the meteorological task, prevents it from running, consequently preventing the blocked information bus task from running. After some time has passed, a watchdog timer goes off, notices that the data bus task has not been executed for some time, concludes that something has gone drastically wrong, and initiate a total system reset. This well reported event actual sequence of events happened on NASA JPL’s Mars Pathfinder spacecraft. Semaphore as a Signal Unfortunately, the term synchronization is often misused in the context of mutual exclusion. Synchronization is, by definition “To occur at the same time; be simultaneous”. Synchronization between tasks is where, typically, one task waits to be notified by another task before it can continue execution (unilateral rendezvous). A variant of this is either task may wait, called the bidirectional rendezvous. This is quite different to mutual exclusion, which is a protection mechanism. However, this misuse has arisen as the counting semaphore can be used for unidirectional synchronization. For this to work, the semaphore is created with a count of 0 (zero). Note that the P and V calls are not used as a pair in the same task. In the example, assuming Task1 calls the P(S) it will block. When Task 2 later calls the V(S) then the unilateral synchronization takes place and both task are ready to run (with the higher priority task actually running). Unfortunately “misusing” the semaphore as synchronization primitive can be problematic in that it makes debugging harder and increase the potential to miss “accidental release” type problems, as an V(S) on its own (i.e. not paired with a P(S)) is now considered legal code. In the next posting I shall look at how the mutex address most of the weaknesses of the semaphore. Posted on September 7th, 2009 Sursa: Sticky Bits

Practical Identification of SQL Injection Vulnerabilities Articol al celor de la CERT-US. by Chad Dougherty Background and Motivation The class of vulnerabilities known as SQL injection continues to present an extremely high risk in the current network threat landscape. In 2011, SQL injection was ranked first on the MITRE Common Weakness Enumeration (CWE)/SANS Top 25 Most Dangerous Software Errors list.1 Exploitation of these vulnerabilities has been implicated in many recent high-profile intrusions. Although there is an abundance of good literature in the community about how to prevent SQL injection vulnerabilities, much of this documentation is geared toward web application developers. This advice is of limited benefit to IT administrators who are merely responsible for the operation of targeted web applications. In this document, we will provide concrete guidance about using open source tools and techniques to independently identify common SQL injection vulnerabilities, mimicking the approaches of attackers at large. We highlight testing tools and illustrate the critical results of testing. Download: http://www.us-cert.gov/reading_room/Practical-SQLi-Identification.pdf

[h=1]Bulletin (SB12-226)[/h][h=2]Vulnerability Summary for the Week of August 6, 2012[/h] Original Release date: Aug 13, 10:14 | Last revised: - The US-CERT Cyber Security Bulletin provides a summary of new vulnerabilities that have been recorded by the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) in the past week. The NVD is sponsored by the Department of Homeland Security (DHS) National Cyber Security Division (NCSD) / United States Computer Emergency Readiness Team (US-CERT). For modified or updated entries, please visit the NVD, which contains historical vulnerability information. The vulnerabilities are based on the CVE vulnerability naming standard and are organized according to severity, determined by the Common Vulnerability Scoring System (CVSS) standard. The division of high, medium, and low severities correspond to the following scores: High - Vulnerabilities will be labeled High severity if they have a CVSS base score of 7.0 - 10.0 Medium - Vulnerabilities will be labeled Medium severity if they have a CVSS base score of 4.0 - 6.9 Low - Vulnerabilities will be labeled Low severity if they have a CVSS base score of 0.0 - 3.9 Entries may include additional information provided by organizations and efforts sponsored by US-CERT. This information may include identifying information, values, definitions, and related links. Patch information is provided when available. Please note that some of the information in the bulletins is compiled from external, open source reports and is not a direct result of US-CERT analysis. Link: http://www.us-cert.gov/cas/bulletins/SB12-226.html Doar asa, ca sa vedeti "cat de repede merg lucrurile"...

Cum scrie si aici, folosind Microsoft Security Bulletin MS10-061 - Critical : Vulnerability in Print Spooler Service Could Allow Remote Code Execution (2347290) in retelele locale, si metoda clasica: USB. Din cate stiu eu nu au fost foarte multe infectii, pentru ca tintele/victimele erau "alese".

Defineste " am 'facut' "

[h=2]Contents of ClubHACK Magazine August 2012:[/h]August 14, 2012 - 3:09 pm By Mayuresh ClubHACK has released the August 2012 version of their magazine. It is the first Indian “Hacking” Magazine. The 31st issue though available now, will be officially released at c0c0n 2012 – International Cyber Security Conference. This ClubHACK magazine edition focuses on Malware Memory Forensics in TechGyan, Apple iOS vulnerablities in Mom’s Guide, Tamper Data in ToolGyan and Matriux Ec-Centric which too will be released at c0c0n. [h=2]Contents of ClubHACK Magazine August 2012:[/h] Tech Gyan: Malware Memory Forensics Memory Forensics is the analysis of the memory image taken from the running computer. In this ClubHACK article, we will learn how to use Memory Forensic Toolkits such as Volatility to analyze the memory artifacts with practical real life forensics scenario. Why Memory Forensics? Memory forensics can help in extracting forensics artifacts from a computer’s memory like running process, network connections, loaded modules etc etc. It can also help in unpacking, rootkit detection and reverse engineering. Legal Gyan: VARIOUS AUTHORITIES UNDER THE IT ACT CCA is appointed by the Central Government under section 17 of the IT Act. Some of the functions of CCA are – To exercise supervision over the activities of Certifying Authorities; To supervise public keys of the Certifying Authorities; To lay down the standards to be maintained by the Certifying Authorities; To specify the qualifications and experience which employees of the Certifying Authorities should possess; To specify the conditions subject to which the Certifying Authorities shall conduct their business; Tool Gyan: Tamper Data What is Tamper Data? Tamper data, an add-on (extension) for Mozilla Firefox, is a fast, simple yet effective tool which can used to do penetration testing. Tamper Data basically gives us the power to view, record and even modify outgoing HTTP requests. Since Tamper data is integrated into the browser, so it has no problems with the HTTPS connections, client authentication certificates or other features that the browser supports. We can trace and time the http/https connections, responses and parameters being sent. Matriux Vibhag: Matriux Ec-Centric Matriux has been successfully running and getting a big support over the past 2 years and we have been working hard to provide the best security solutions and quality tools for all the penetration testing and forensic needs. On occasion this issue is to be released at c0c0n 2012, we are also proud to announce our upcoming release Matriux version 2.0 K0d3 name “Ec-Centric”. We have been working hard over the release of the new version, so this month the ClubHACK Matriux Vibhag will feature the Matriux Ec-Centric edition. Mom’s Guide: Apple iOS vulnerabilities Apple iOS has successfully emerged as one of the most widely used Operating System today. It runs on Apple devices such as iPhone, iPad, iPod touch and Apple TV. Apple AppStore has the highest number of applications (500,000) with 25 billion apps downloaded till date. However, the iOS developers aren’t bothered about the secure aspect of the applications before they launch it on the AppStore. This huge number of apps and carelessness of developers has lured the hackers to steal data from the applications. Code Gyan: Basics of Android Secure Coding Android is an OS designed for Smart phones. The phones are meant for office productivity apps, games, social networks etc. The phone comes pre-installed with a selection of system applications, e.g., phone dialer, address book, but the platform gives ample opportunities for the developers to create their own applications and publish into the huge android market, so called the “Play Store”. Special Feature: Impact of Cybercrime on Businesses IT security is more important for businesses than ever. A study that was carried out by the Ponemon Institute has revealed that businesses lacking in IT security could be losing over £200,000. The study, entitled “Impact of Cybercrime on Businesses”, surveyed 2,618 C-level IT security and executive personnel with the aim of finding out what everyone has in common. The survey spanned the United States, United Kingdom, Hong Kong, Brazil and Germany. It was found that in the latter country, cyber-attacks cost businesses more than anywhere else, with the average cost being around $298,359. The average cost that cyber-attacks will have on companies in the United States is $276,671, if they are successfully carried out. [h=3]Download ClubHACK Magazine:[/h] ClubHACK Magazine Issue 31, August 2012 – aug2012.pdf Sursa: ClubHACK Magazine August 2012! — PenTestIT

WebCodeSniffer WebCodeSniffer is a web version of PHP_CodeSniffer. It allows you to use easely PHP_CodeSniffer in your browser on a local or remote server. No PEAR, no CLI needed. This tool will help you to follow guidelines when coding in order to reduce bugs, prevent new bugs and have a code clean, consistent and easy to read and maintain. About PHP_CodeSniffer "PHP_CodeSniffer is a PHP5 script that tokenises PHP, JavaScript and CSS files to detect violations of a defined set of coding standards. It is an essential development tool that ensures your code remains clean and consistent. It can also help prevent some common semantic errors made by developers". - http://pear.php.net/package/PHP_CodeSniffer - https://github.com/squizlabs/PHP_CodeSniffer - http://www.squizlabs.com/php-codesniffer About Coding Standards / Coding Conventions "Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices and methods for each aspect of a piece program written in this language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, etc. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier." - http://en.wikipedia.org/wiki/Coding_conventions - http://pear.php.net/manual/en/standards.php - http://www.phptherightway.com/ Download: http://www.webcodesniffer.net/index.php

There are currently 166 users browsing this thread. (11 members and 155 guests)

There are currently 147 users browsing this thread. (4 members and 143 guests)

Facem exceptii pentru tine

Eu m-am plictisit de Polinic, nu mai e nimic amuzant

Mergem prin Buzau sa punem stickere?

ASEF - Android Security Evaluation Framework Please refer the following blog post for in-depth design and details about A S E F :- 1) A S E F Intro Blog : https://community.qualys.com/blogs/securitylabs/2012/07/25/android-security-evaluation-framework--a-s-e-f 2) A S E F Getting Started : https://community.qualys.com/docs/DOC-3675 (Guide in .pdf -https://community.qualys.com/servlet/JiveServlet/downloadBody/3675-102-4-6580/ASEF-Blog(4).pdf) Abstract : Have you ever looked at your Android applications and wondered if they are watching you as well? Whether it's a bandwidth-hogging app, aggressive adware or even malware, it would be interesting to know if they are doing more than what they are supposed to and if your personal information is exposed. Is there really a way to automatically evaluate all your apps - even hundreds of them - to harvest their behavioral data, analyze their run pattern, and at the same time provide an interface to facilitate a vast majority of evolving security tests with most practical solutions? Android Security Evaluation Framework (ASEF) performs this analysis while alerting you about other possible issues. It will make you aware of unusual activities of your apps, will expose vulnerable components and help narrow down suspicious apps for further manual research. The framework will take a set of apps (either pre-installed on a device or as individual APK files) and migrate them to the test suite where it will run it through test cycles on a pre-configured Android Virtual Device (AVD). During the test cycles the apps will be installed and launched on the AVD. ASEF will trigger certain behaviors by sending random or custom gestures and later uninstall the app automatically. It will capture log events, network traffic, kernel logs, memory dump, running processes and other parameters at every stage which will later be utilized by the ASEF analyzer. The analyzer will try to determine the aggressive bandwidth usage, interaction with any command and control (C&C) servers using Google's safe browsing API, permission mappings and known security flaws. ASEF can easily be integrated with other open source tools to capture sensitive information, such as SIM cards, phone numbers and others. ASEF is an Open Source tool for scanning Android Devices for security evaluation. Users will gain access to security aspects of android apps by using this tool with its default settings. An advanced user can fine-tune this, expand upon this idea by easily integrating more test scenarios, or even find patterns out of the data it already collects. ASEF will provide automated application testing and facilitate a plug and play kind of environment to keep up with the dynamic field of Android Security. Download: https://code.google.com/p/asef/downloads/list Info: https://code.google.com/p/asef/

Tabel `substantive`: ----------------------------------- id | tip | substantiv | alte date | ----------------------------------- 1 | 1 | dfgdfgf | dffgdf | 2 | 1 | fgfgdfg | gfhjhj | 3 | 2 | hjhjh | hghgh | 4 | 1 | fgfgf | fhgh | ----------------------------------- Unde tip == 1 inseamna comun, iar tip == 2 inseamna propriu.

dfgdfgdgd

Da, am observat, mersi. E din cauza forumului, incepe cu un numar, si cauta automat acel thread. Am modificat titlul, dar e posibil sa nu mearga din cauza unui cache stupid.

Aici? https://rstcenter.com/forum/external.php

[h=3]Researchers uncover security holes in China-based Huawei routers[/h] Routers made by China-based Huawei Technologies have very few modern security protections and easy-to-find vulnerabilities, two network-security experts stated at the Defcon hacking convention. Huawei is one of the fastest-growing network and telecommunications equipment makers in the world. The vulnerabilities were discovered and presented by Felix Lindner and Gregor Kopf of the security firm Recurity Labs. They talks about three vulnerabilities demonstrated at the Defcon conference, which included a session hijack, a heap overflow, and a stack overflow, and the discussion of more than 10,000 calls in the firmware code that went to sprintf, an insecure function. The problem is due to the use of "1990s-style code" in the firmware of some Huawei VRP routers, he said. (The models are the Huawei AR18 and AR 29 series). With a known exploit, an attacker could get access to the systems, log in as administrator, change the admin passwords and reconfigure the systems, which would allow for interception of all the traffic running through the routers. Both Lindner and Kopf have criticized Huawei for not having a security contact, as well as for its lack of security advisories for its products. Additionally, the researchers say firmware updates don't talk about bugs that may have been fixed. A U.S.-based Huawei representative provided CNET with the following statement: We are aware of the media reports on security vulnerabilities in some small Huawei routers and are verifying these claims. Huawei adopts rigorous security strategies and policies to protect the network security of our customers and abides by industry standards and best practices in security risk and incident management. Huawei has established a robust response system to address product security gaps and vulnerabilities, working with our customers to immediately develop contingency plans for all identified security risks, and to resolve any incidents in the shortest possible time. In the interests of customer security, Huawei also calls on the industry to promptly report all product security risks to the solutions provider so that the vendor's CERT team can work with the relevant parties to develop a solution and roll-out schedule. Sursa: Researchers uncover security holes in China-based Huawei routers | The Hacker News