- Update HISTORY.md
- Commit the changes:
git add HISTORY.md
git commit -m "Changelog for upcoming release 0.1.1."
- Update version number (can also be minor or major)
bumpversion patch
#!/usr/bin/env ruby | |
# | |
# Proof-of-Concept exploit for Rails Remote Code Execution (CVE-2013-0156) | |
# | |
# ## Advisory | |
# | |
# https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion | |
# | |
# ## Caveats | |
# |
git add HISTORY.md
git commit -m "Changelog for upcoming release 0.1.1."
bumpversion patch
As a good crypto nerd, I usually use an entirely encrypted linux FS: /
but also
/boot
using grub LUKS support. It's a good setup but it's not perfect, the BIOS and
the bootloader are not protected.
I recently got a USBArmory and I wanted to apply the same (or a better) setup.
I found some useful links but no clear howto. So this is my setup.
// WCTF 2018 "searchme" task exploit | |
// | |
// Author: Mateusz "j00ru" Jurczyk | |
// Date: 6 July 2018 | |
// Tested on: Windows 10 1803 (10.0.17134.165) | |
// | |
// See also: https://j00ru.vexillium.org/2018/07/exploiting-a-windows-10-pagedpool-off-by-one/ | |
#include <Windows.h> | |
#include <winternl.h> | |
#include <ntstatus.h> |
Troubleshooting a running application can be difficult, usually it starts around checking log output and then following through the likely code paths to get an idea of where a failure may occur. In a development environment, you might attach a debugger a step through source, but troubleshooting isn't always that convenient. There are several helpful tools that can assist, but one that gives the most comprehensive view of a running application is strace
. With strace
you are able to see all of the system calls an application makes to get a detailed understanding of what is going on "under the hood" in order to troubleshoot an issue.
Take a simple "hello world" F# application, the kind you get from dotnet new console -lang F# -n strace-sample"
. Build it with dotnet build
and then launch it with strace
to get a trace of all the system calls in a file called trace.log
(adjusting for your build output path if on a different framework vers
I have done some preliminary research into this bug and so far it does not seem like a backdoor. Just some really weird logic when handling routes, and rendering templates. | |
As to why widgetConfig[code] executes via a POST request, it is because of the following code located in /includes/vb5/frontend/applicationlight.php | |
$serverData = array_merge($_GET, $_POST); | |
if (!empty($this->application['handler']) AND method_exists($this, $this->application['handler'])) | |
{ | |
$app = $this->application['handler']; |