Planet

pkg upgrade: Certificate verification failed for /C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 2 IV Server CA

Postby Dan Langille via Dan Langille's Other Diary »

I noticed this on one FreeBSD server today: $ pkg -vv | grep url url: "pkg+http://services.unixathome.org/packages/103amd64-default-master-list/", I decided: let’s use https, not http, there. After making the change (in my case, it was in /usr/local/etc/pkg/repos/local.conf, I tried upgraded packages, and it barfed: $ sudo pkg upgrade Updating local repository catalogue... Certificate verification failed for /C=IL/O=StartCom [...]
Top

Netbooting FreeBSD with PXE/UEFI

Postby gonzo via FreeBSD developer's notebook | All Things FreeBSD »

Dear Future Me,

I guess you came here googling for “FreeBSD PXE UEFI” trying to find out how to netboot your x86 dev box. Or arm64 box. Who knows what you’re hacking on in the future. To do that you need follow these simple steps:

  • Put loader.efi to tftpboot dir
  • Configure dhcpd along these lines:
    host amd64 {
            hardware ethernet  b8:ae:ed:77:88:99;
            filename "loader.efi";
            option root-path "/src/FreeBSD/tftproot/amd64";
            fixed-address 192.168.10.102;
            option routers 192.168.10.1;
    }
    
  • Make sure root-path is in /etc/exports.
  • If you use MINIMAL-derived config add your NIC driver to /boot/loader.conf:
    if_re_load="YES"
    
That’s pretty much it.

Take care
Top

‘Money Mule’ Gangs Turn to Bitcoin ATMs

Postby BrianKrebs via Krebs on Security »

Fraudsters who hack corporate bank accounts typically launder stolen funds by making deposits from the hacked company into accounts owned by “money mules,” willing or unwitting dupes recruited through work-at-home job scams. The mules usually are then asked to withdraw the funds in cash and wire the money to the scammers. Increasingly, however, the mules are being instructed to remit the stolen money via Bitcoin ATMs.

I recently heard from a reader in Canada who said she’d recently accepted a job as a customer service officer for a company called LunarBay. This company claims to be a software development firm, and told this reader they needed to hire people to help process payments for LunarBay’s clients.

LunarBay’s Web site — Lunarbay[dot]biz — claims the company has been in business for several years, and even references a legitimate business by the same name in the United Kingdom. But the domain name was registered only in late August 2016, and appears to have lifted all of its content from a legitimate Australian digital marketing firm called Bonfire.

The Canadian reader who contacted KrebsOnSecurity about this scam was offered $870 per week and a five percent commission on every transaction she handled. After providing her bank account information to get paid, she became suspicious when she received instructions on how to forward funds on the LunarBay.

The scammers told her to withdraw the money from her account by going into the bank itself — not from the ATM (mainly due to daily withdrawal limits at the ATM). They also sent her a QR code (pictured below) that she was instructed to save as an image on her smartphone. The crooks then proceeded to tell her the location of the nearest Bitcoin ATM:

a) The nearest Bitcoin ATM is located at: 6364 Rue Pascal, Montréal-Nord, QC H1G 1T6, Canada (Bitcoin ATM is located at Dépanneur Pascal 2003 convenience shop in Montreal).

b) You can find the instructions of how to make payment using Bitcoin ATM in this video

c) Please find the image attached to this message. This is a QR code – an unique identification number for a transaction. I ask you to save this image to your smartphone beforehand.

4. The payment must be processed within 3 hours. The Bitcoin rate is constantly changing in relation to CAD, USD and other currencies. That’s why the payment must be made during this time interval.

As the above Youtube video demonstrates, sending funds merely requires the user to scan a QR code shared by the intended recipient, and then insert cash into the Bitcoin ATM. Because Bitcoin is a non-refundable form of payment, once the money is sent the transaction cannot be reversed.

It’s not immediately clear why these thieves are avoiding tried-and-true methods of disbursing cash — like Western Union and MoneyGram — in favor of Bitcoin ATMs. I suppose it’s possible that the wire transfer companies are getting better at detecting and blocking suspicious transactions, but I doubt that’s the reason. More likely, sending cash via Bitcoin results in a more immediate payday for the scammers, and avoids the costs and hassle associated with hiring “far-end” mules to collect fraudulent wire transfers in the scammer’s home country.

The QR code used by the scammers at the fake LunarBay company.
It may seem difficult to believe that people might be gullible enough to get embroiled in such money laundering scams, but countless individuals do every day. The crooks operating this scam no doubt use multiple QR codes linked to many different Bitcoin addresses. The one given to the reader who contacted me links to this Bitcoin account, which has received a total of eight transactions over three days this past week totaling more than 6.3 Bitcoins — roughly $3,823 at current exchange rates.

Word to the wise: Money mule scammers specialize in hacking employer accounts at job recruitment Web sites like Monster.com, Hotjobs.com and other popular employment search services. Armed with the employer accounts, the crooks are free to search through millions of resumes and reach out to people who are currently between jobs or seeking part-time employment.

If you receive a job solicitation via email that sounds too-good-to-be-true, it probably is related in some way to one of these money-laundering schemes. Even if you can’t see the downside to you, someone is likely getting ripped off. Also, know that money mules — however unwitting — may find themselves in hot water with local police, and may be asked by their bank to pay back funds that were illegally transferred into the mules’ account.

For more on the crucial role of money mules in facilitating cybercrime, check out these stories.
Top

FreeBSD 11.0-RELEASE Status Update

Postby Webmaster Team via FreeBSD News Flash »

The final 11.0-RELEASE is going to be rebuilt in order to address a few last-minute items that were discovered after the release tag. Please see the official announcement from the Release Engineering team for more information.
Top

Inside Arizona’s Pump Skimmer Scourge

Postby BrianKrebs via Krebs on Security »

Crooks who deploy skimming devices made to steal payment card details from fuel station pumps don’t just target filling stations at random: They tend to focus on those that neglect to deploy various tools designed to minimize such scams, including security cameras, non-standard pump locks and tamper-proof security tape. But don’t take my word for it: Here’s a look at fuel station compromises in 2016 as documented by the state of Arizona, which has seen a dramatic spike in fuel skimming attacks over the past year.

KrebsOnSecurity examined nearly nine months worth of pump skimming incidents in Arizona, where officials say they’ve documented more skimming attacks in the month of August 2016 alone than in all of 2015 combined.

With each incident, the Arizona Department of Agriculture’s Weights and Measures Services Division files a report detailing whether victim fuel station owners had observed industry best practices leading up to the hacks. As we can see from the interactive story map KrebsOnSecurity created below, the vast majority of compromised filling stations failed to deploy security cameras, and/or tamper-evident seals on the pumps.

Fewer still had changed the factory-default locks on their pumps, meaning thieves armed with a handful of master keys were free to unlock the pumps and install skimming devices at will.

These security report cards for fuel station owners aren’t complete assessments by any means. Some contain scant details about the above-mentioned precautionary measures, while other reports painstakingly document such information — complete with multiple photos of the skimming devices. Regardless, the data available show a clear trend of fraudsters targeting owners and operators that flout basic security best practices.

Indeed, the data assembled here suggests that skimmer thieves favor off-brand filling stations and target pumps furthest from the station/closest to the street. Also, all but three of the 35 incidents included in this report targeted fuel dispensers made by one manufacturer: Gilbarco — probably because the skimmer thieves responsible were armed with a master key for Gilbarco pumps.

In only one documented skimming incident did the station owner report having used non-standard pump locks. In some cases, the same filling station was hit with separate skimming attacks just a few months apart.

A portion of the incident report for the Bluetooth skimmers found at a gas station in Phoenix on Sept. 6, 2016
Investigators also appear to be increasingly finding pump skimmers that employ Bluetooth wireless technology. Bluetooth-based skimmers allow thieves to collect stolen card data merely by pulling up to a pump and downloading it with a Bluetooth-enabled laptop or mobile device (as opposed to taking the risk of re-opening the pumps to retrieve the siphoned card data).

A review of the locations of the skimmed stations suggests that skimmer scammers prefer poorly secured stations that are quite close to a major highway, no doubt so that they get away from the station relatively quickly after the skimmers are planted. It’s unclear whether the skimming attacks documented here are the work of one or multiple scammers or gangs, but the activity pretty clearly shows a focus on stations directly off the main arteries from Phoenix on down to Tuscon.



In some of the images in the slideshow above, it may be difficult to readily tell among the jumble of wires which bit is the skimmer. When in doubt, look for an area wrapped in black or grey colored electrical tape, which seems to be found in nearly all of these pump skimming attacks.

Arizona is almost certainly a microcosm of pump skimming activity going on nationally. Last year, KrebsOnSecurity ran an in-depth piece profiling a U.S. Secret Service task force that’s been battling a surge in pump skimming scams perpetrated by organized crime gangs in and around Los Angeles. Other stories on pump skimmers can be found in this search link.

Consumers should remember that they’re not liable for fraudulent charges on their credit or debit cards, but they still have to report the phony transactions. There is no substitute for keeping a close eye on your card statements. Also, use credit cards instead of debit cards at the pump; having your checking account emptied of cash while your bank sorts out the situation can be a huge hassle and create secondary problems (bounced checks, for instance).

I realize that the project above — made with the free StoryMap tool from Northwestern University’s Knight Lab — may be difficult to view comfortably within the confines of this blog. Here’s a direct link to the full map and timeline.
Top

We do not ship SELinux sandbox

Postby Sven Vermeulen via Simplicity is a form of art... »

A few days ago a vulnerability was reported in the SELinux sandbox user space utility. The utility is part of the policycoreutils package. Luckily, Gentoo's sys-apps/policycoreutils package is not vulnerable - and not because we were clairvoyant about this issue, but because we don't ship this utility.

What is the SELinux sandbox?

The SELinux sandbox utility, aptly named sandbox, is a simple C application which executes its arguments, but only after ensuring that the task it launches is going to run in the sandbox_t domain.

This domain is specifically crafted to allow applications most standard privileges needed for interacting with the user (so that the user can of course still use the application) but removes many permissions that might be abused to either obtain information from the system, or use to try and exploit vulnerabilities to gain more privileges. It also hides a number of resources on the system through namespaces.

It was developed in 2009 for Fedora and Red Hat. Given the necessary SELinux policy support though, it was usable on other distributions as well, and thus became part of the SELinux user space itself.

What is the vulnerability about?

The SELinux sandbox utility used an execution approach that did not shield off the users' terminal access sufficiently. In the POC post we notice that characters could be sent to the terminal through the ioctl() function (which executes the ioctl system call used for input/output operations against devices) which are eventually executed when the application finishes.

That's bad of course. Hence the CVE-2016-7545 registration, and of course also a possible fix has been committed upstream.

Why isn't Gentoo vulnerable / shipping with SELinux sandbox?

There's some history involved why Gentoo does not ship the SELinux sandbox (anymore).

First of all, Gentoo already has a command that is called sandbox, installed through the sys-apps/sandbox application. So back in the days that we still shipped with the SELinux sandbox, we continuously had to patch policycoreutils to use a different name for the sandbox application (we used sesandbox then).

But then we had a couple of security issues with the SELinux sandbox application. In 2011, CVE-2011-1011 came up in which the seunshare_mount function had a security issue. And in 2014, CVE-2014-3215 came up with - again - a security issue with seunshare.

At that point, I had enough of this sandbox utility. First of all, it never quite worked enough on Gentoo as it is (as it also requires a policy which is not part of the upstream release) and given its wide open access approach (it was meant to contain various types of workloads, so security concessions had to be made), I decided to no longer support the SELinux sandbox in Gentoo.

None of the Gentoo SELinux users ever approached me with the question to add it back.

And that is why Gentoo is not vulnerable to this specific issue.
Top

Changing the default host for Cisco AnyConnect OSX client

Postby Dan Langille via Dan Langille's Other Diary »

My first day back from EuroBSDCon 2016, I wanted to fix an issue which arose before the conference. My Cisco AnyConnect client configuration contained old hosts which I no longer used, but didn’t contain the host I was primarily using now. I could add the host, but upon restart, that new host was no longer [...]
Top

Fn Backlight auf XC1506 zum laufen bringen

Postby bed via Zockertown: Nerten News »

Eigentlich lief ja alles zur vollsten Zufriedenheit auf meinem Tuxedo Laptop... Doch was macht der Esel, wenn's ihm zu gut geht? Richtig, er geht auf's Eis.

Will sagen, so richtig glücklich bin ich mit Ubuntu nicht. Keine Frage, die Unterstützung von proprietäre Hardware (NVidia) ist spitze, aber ich mag Unity nicht, hatte Gnome3 Shell installiert und es ging bis auf die Fn Backlightsteuerung im Gnome alles einwandfrei. Das habe ich mit einem xbindkeys auf andere Tasten gelegt, damit wäre eigentlich alles geregelt.

Doch mich stört dieser sudo Mist, klar, auch das hätte ich abschalten können, aber ich wollte aufs Eis und wieder zurück zur Mutter.

Also habe ich Debian Stretch (noch im Testing) installiert, was gar nicht so einfach war, weil ich die Volumegroups behalten wollte. Schließlich habe ich es hinbekommen und bis auf die Helligkeitsverstellung des Backlights ging alles out of the Box. Ich habe noch das Modul von Tuxedo installiert, tuxedo-wmi.

Interessanterweise war die Desktop Notification bereits funktionsfähig, nur das Backlight scherte sich nicht und blieb auf einer Stufe stehen. Der Wert der Helligkeitsstufe wurde allerdings hier

/sys/class/backlight/acpi_video0/actual_brightness
geschrieben. Das war ein guter Beginn.

Um es kurz zu machen, die Lösung ist jetzt inotify-tools installieren und dann:

Eintrag in /etc/default/grub für Tuxedo XC1506

# Eintrag in /etc/default/grub
# Wichtig ist, dass man nicht! acpi_backlight=vendor setzt!
    $ grep ^GRUB_CMDLINE_LINUX_DEFAULT= /etc/default/grub
    GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_os_name=Linux acpi_osi= acpi_backlight=video vga=791"

Dieses Script überwacht mit inotify die Änderungen in actual_brightness

Das Script ist eine Modification von hier

# Dieses Script überwacht mit inotify die Änderungen in actual_brightness
$ cat /usr/local/bin/xbacklightmon
#!/bin/bash

    path=/sys/class/backlight/acpi_video0

    read -r max < "$path"/max_brightness

    luminance() {
        read -r level < "$path"/actual_brightness
        factor=10
        printf '%d\n' "$(( $level * $factor))"
    }


    xbacklight -set "$(luminance)"

    inotifywait -me modify --format '' "$path"/actual_brightness | while read; do
        xbacklight -set "$(luminance)"
    done

Der Autostart Eintrag

# Der Autostart Eintrag
$ cat .config/autostart/xbacklightmon.desktop
    [Desktop Entry]
    Type=Application
    Exec=/usr/local/bin/xbacklightmon
    Hidden=false
    X-GNOME-Autostart-enabled=true
    Name[de_de]=xbacklightmon
    Name=xbacklightmon
    Comment[de_de]=Workaround fürs backlight



Top

This week in vc4 (2016-09-26): XDC 2016, glamor testing, glamor performance

Postby Eric Anholt via anholt's lj »

Last week I spent at XDS 2016 with other graphics stack developers.

I gave a talk on X Server testing and our development model.  Since playing around in the Servo project (and a few other github-centric communities) recently, I've become increasingly convinced that github + CI + automatic merges is the right way to go about software development now.  I got a warmer reception from the other X Server developers than I expected, and I hope to keep working on building out this infrastructure.

I also spent a while with keithp and ajax (other core X developers) talking about how to fix our rendering performance.  We've got two big things hurting vc4 right now: Excessive flushing, and lack of bounds on rendering operations.

The excessive flushing one is pretty easy.  X currently does some of its drawing directly to the front buffer (I think this is bad and we should stop, but that *is* what we're doing today).  With glamor, we do our rendering with GL, so the driver accumulates a command stream over time.  In order for the drawing to the front buffer to show up on time, both for running animations, and for that last character you typed before rendering went idle, we have to periodically flush GL's command stream so that its rendering to the front buffer (if any) shows up.

Right now we just glFlush() every time we might block sending things back to a client, which is really frequent.  For a tiling architecture like vc4, each glFlush() is quite possibly a load and store of the entire screen (8MB).

The solution I started back in August is to rate-limit how often we flush.  When the server wakes up (possibly to render), I arm a timer.  When it fires, I flush and disarm it until the next wakeup.  I set the timer to 5ms as an arbitrary value that was clearly not pretending to be vsync.  The state machine was a little tricky and had a bug it seemed (or at least a bad interaction with x11perf -- it was unclear).  But ajax pointed out that I could easily do better: we have a function in glamor that gets called right before it does any GL operation, meaning that we could use that to arm the timer and not do the arming every time the server wakes up to process input.

Bounding our rendering operations is a bit trickier.  We started doing some of this with keithp's glamor rework: We glScissor() all of our rendering to the pCompositeClip (which is usually the bounds of the current window).  For front buffer rendering in X, this is a big win on vc4 because it means that when you update an uncomposited window I know that you're only loading and storing the area covered by the window, not the entire screen.  That's a big bandwidth savings.

However, the pCompositeClip isn't enough.  As I'm typing we should be bounding the GL rendering around each character (or span of them), so that I only load and store one or two tiles rather than the entire window.  It turns out, though, that you've probably already computed the bounds of the operation in the Damage extension, because you have a compositor running!  Wouldn't it be nice if we could just reuse that old damage computation and reference it?

Keith has started on making this possible: First with the idea of const-ifying all the op arguments so that we could reuse their pointers as a cheap cache key, and now with the idea of just passing along a possibly-initialized rectangle with the bounds of the operation.  If you do compute the bounds, then you pass it down to anything you end up calling.

Between these two, we should get much improved performance on general desktop apps on Raspberry Pi.

Other updates: Landed opt_peephole_sel improvement for glmark2 performance (and probably mupen64plus), added regression testing of glamor to the X Server, fixed a couple of glamor rendering bugs.
Top

Mounting QEMU images

Postby Sven Vermeulen via Simplicity is a form of art... »

While working on the second edition of my first book, SELinux System Administration - Second Edition I had to test out a few commands on different Linux distributions to make sure that I don't create instructions that only work on Gentoo Linux. After all, as awesome as Gentoo might be, the Linux world is a bit bigger. So I downloaded a few live systems to run in Qemu/KVM.

Some of these systems however use cloud-init which, while interesting to use, is not set up on my system yet. And without support for cloud-init, how can I get access to the system?

Mounting qemu images on the system

To resolve this, I want to mount the image on my system, and edit the /etc/shadow file so that the root account is accessible. Once that is accomplished, I can log on through the console and start setting up the system further.

Images that are in the qcow2 format can be mounted through the nbd driver, but that would require some updates on my local SELinux policy that I am too lazy to do right now (I'll get to them eventually, but first need to finish the book). Still, if you are interested in using nbd, see these instructions or a related thread on the Gentoo Forums.

Luckily, storage is cheap (even SSD disks), so I quickly converted the qcow2 images into raw images:

~$ qemu-img convert root.qcow2 root.raw
With the image now available in raw format, I can use the loop devices to mount the image(s) on my system:

~# losetup /dev/loop0 root.raw
~# kpartx -a /dev/loop0
~# mount /dev/mapper/loop0p1 /mnt
The kpartx command will detect the partitions and ensure that those are available: the first partition becomes available at /dev/loop0p1, the second /dev/loop0p2 and so forth.

With the image now mounted, let's update the /etc/shadow file.

Placing a new password hash in the shadow file

A google search quickly revealed that the following command generates a shadow-compatible hash for a password:

~$ openssl passwd -1 MyMightyPassword
$1$BHbMVz9i$qYHmULtXIY3dqZkyfW/oO.
The challenge wasn't to find the hash though, but to edit it:

~# vim /mnt/etc/shadow
vim: Permission denied
The image that I downloaded used SELinux (of course), which meant that the shadow file was labeled with shadow_t which I am not allowed to access. And I didn't want to put SELinux in permissive mode just for this (sometimes I /do/ have some time left, apparently).

So I remounted the image, but now with the context= mount option, like so:

~# mount -o context="system_u:object_r:var_t:s0: /dev/loop0p1 /mnt
Now all files are labeled with var_t which I do have permissions to edit. But I also need to take care that the files that I edited get the proper label again. There are a number of ways to accomplish this. I chose to create a .autorelabel file in the root of the partition. Red Hat based distributions will pick this up and force a file system relabeling operation.

Unmounting the file system

After making the changes, I can now unmount the file system again:

~# umount /mnt
~# kpart -d /dev/loop0
~# losetup -d /dev/loop0
With that done, I had root access to the image and could start testing out my own set of commands.

It did trigger my interest in the cloud-init setup though...
Top

Untethering Jetson-TK1

Postby gonzo via FreeBSD developer's notebook | All Things FreeBSD »

Normally I netboot all my ARM devices but in case of Jetson TK1 I thought it would be nice to go and try to make it “real computer” – running by itself, may be use it for some port builds. I added Samsung EVO to it but the plan was to use SSD for builds/source code, and to use either external SD card or eMMC as a root device. TK1 survived buildworld/buildkernel (I had to add swap though, clang is a memory monster) so it was time to populate root device and eMMC was picked as a target. There were some ms-basic-data partitions on eMMC but I didn’t think much of it and happily typed dd if=/dev/zero of=/dev/mmcsd0 bs=128m. Well… Big mistake. Among those partitions was u-boot. And probably earlier stage boot loader as well. So I had to install ubuntu on one of unused machines and re-flash TK1. Luckily no permanent damage was done to the device. After this accident I added a little bit of planning into the process. Here is short summary:

Default eMMC partition looks like this:

Tegra124 (Jetson TK1) #  mmc part

Partition Map for MMC device 0  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00017000      0x01c16fff      "APP"
        attrs:  0x0001000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   7369c667-ff51-ec4a-29cd-baabf2fbe346
  2     0x01c17000      0x01c18fff      "DTB"
        attrs:  0x0002000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   f854c27c-e81b-8de7-765a-2e63339fc99a
  3     0x01c19000      0x01c38fff      "EFI"
        attrs:  0x0003000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   b70d3266-5831-5aa3-255d-051758e95ed4
  4     0x01c39000      0x01c3afff      "USP"
        attrs:  0x0004000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   c6cdb2ab-b49b-1154-0e82-7441213ddc87
  5     0x01c3b000      0x01c3cfff      "TP1"
        attrs:  0x0005000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   a13ee970-e141-67fc-3e01-7e97eadc6b96
  6     0x01c3d000      0x01c3efff      "TP2"
        attrs:  0x0006000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   2a5c388f-b0ec-fb3b-32af-3c54ec18db5c
  7     0x01c3f000      0x01c40fff      "TP3"
        attrs:  0x0007000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   43fe1a02-fafb-3aaa-fb29-d1e6053c7c94
  8     0x01c41000      0x01c41fff      "WB0"
        attrs:  0x0008000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   61bed875-f989-bb5c-a899-0f95b1ebf1b3
  9     0x01c42000      0x01d58fff      "UDA"
        attrs:  0x0009000000000001
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   00f7ef05-a1e9-e53a-ca0b-cbd0484764bd
We need two things to make TK1 bootable: place ubldr on flash so u-boot can load it and create rootfs. The latter one is simple: APP partition is the one to be user as root. For the former either of TPx partitions can be used, TP stands for “Temporary Placeholder” and can be used for app-specific tasks. All three TPx are just 4Mb but ubldr is small enough to fit just fine. So let’s place ubldr to TP1:

# newfs_msdos /dev/gpt/TP1
# mount_msdosfs /dev/gpt/TP1 /mnt
# cp ubldr.tk1 /mnt/
# umount /mnt
Then populate rootfs:

# newfs /dev/gpt/APP
# mount /dev/gpt/APP /mnt
Then build/install stuff: … buildworld, buildkernel. installworld, distribution and installkernel with DESTDIR=/mnt …

Create /etc/fstab so kernel would pick up correct rootfs location. I also use nullfs to mount /tmp to the directory on SSD drive, and added swap file on SSD.

/dev/gpt/APP /       ufs     rw,noatime     0       0
/dev/ada0    /src    ufs     rw,noatime     0       0
md99         none    swap    sw,file=/src/swap,late      0       0
/src/tmp     /tmp    nullfs  rw             0       0
# umount /mnt
Reboot to u-boot and set up boot command:

Tegra124 (Jetson TK1) # setenv bootcmd 'fatload mmc 0:5 $loadaddr ubldr.tk1; bootelf'
Tegra124 (Jetson TK1) # saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
Tegra124 (Jetson TK1) # boot
That’s it. Also if I need to revert back to netbooting TK1 I can just set loaderdev to “net” in u-boot:

Tegra124 (Jetson TK1) # setenv loaderdev net; boot
Top

mupdf: mujstest: strcpy-param-overlap in main (jstest_main.c)

Postby ago via agostino's blog »

Description:
Mujstest, which is part of mupdf is a scriptable tester for mupdf + js.

A fuzzing revealed a strcpy-param-overlap.

The complete ASan output:

# mujstest $FILE
==26843==ERROR: AddressSanitizer: strcpy-param-overlap: memory ranges [0x0000013c5d40,0x0000013c62ed) and [0x0000013c6285, 0x0000013c6832) overlap
    #0 0x473129 in __interceptor_strcpy /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:545
    #1 0x4f7910 in main /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/platform/x11/jstest_main.c:353:6
    #2 0x7f8af37a961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #3 0x41ade8 in _init (/usr/bin/mujstest+0x41ade8)

0x0000013c6140 is located 0 bytes to the right of global variable 'filename' defined in 'platform/x11/jstest_main.c:15:13' (0x13c5d40) of size 1024
0x0000013c6285 is located 5 bytes inside of global variable 'getline_buffer' defined in 'platform/x11/jstest_main.c:24:13' (0x13c6280) of size 4096
SUMMARY: AddressSanitizer: strcpy-param-overlap /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:545 in __interceptor_strcpy
==26843==ABORTING
Affected version:
1.9a

Fixed version:
2.0 (not yet released)

Commit fix:
http://git.ghostscript.com/?p=mupdf.git;h=cfe8f35bca61056363368c343be36812abde0a06

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-04: bug discovered
2016-08-05: bug reported to upstream
2016-09-22: upstream released a patch
2016-09-25: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

mupdf: mujstest: strcpy-param-overlap in main (jstest_main.c)

Top

The Democratization of Censorship

Postby BrianKrebs via Krebs on Security »

John Gilmore, an American entrepreneur and civil libertarian, once famously quipped that “the Internet interprets censorship as damage and routes around it.” This notion undoubtedly rings true for those who see national governments as the principal threats to free speech.

However, events of the past week have convinced me that one of the fastest-growing censorship threats on the Internet today comes not from nation-states, but from super-empowered individuals who have been quietly building extremely potent cyber weapons with transnational reach.



More than 20 years after Gilmore first coined that turn of phrase, his most notable quotable has effectively been inverted — “Censorship can in fact route around the Internet.” The Internet can’t route around censorship when the censorship is all-pervasive and armed with, for all practical purposes, near-infinite reach and capacity. I call this rather unwelcome and hostile development the “The Democratization of Censorship.”

Allow me to explain how I arrived at this unsettling conclusion. As many of you know, my site was taken offline for the better part of this week. The outage came in the wake of a historically large distributed denial-of-service (DDoS) attack which hurled so much junk traffic at Krebsonsecurity.com that my DDoS protection provider Akamai chose to unmoor my site from its protective harbor.

Let me be clear: I do not fault Akamai for their decision. I was a pro bono customer from the start, and Akamai and its sister company Prolexic have stood by me through countless attacks over the past four years. It just so happened that this last siege was nearly twice the size of the next-largest attack they had ever seen before. Once it became evident that the assault was beginning to cause problems for the company’s paying customers, they explained that the choice to let my site go was a business decision, pure and simple.

Nevertheless, Akamai rather abruptly informed me I had until 6 p.m. that very same day — roughly two hours later — to make arrangements for migrating off their network. My main concern at the time was making sure my hosting provider wasn’t going to bear the brunt of the attack when the shields fell. To ensure that absolutely would not happen, I asked Akamai to redirect my site to 127.0.0.1 — effectively relegating all traffic destined for KrebsOnSecurity.com into a giant black hole.

Today, I am happy to report that the site is back up — this time under Project Shield, a free program run by Google to help protect journalists from online censorship. And make no mistake, DDoS attacks — particularly those the size of the assault that hit my site this week — are uniquely effective weapons for stomping on free speech, for reasons I’ll explore in this post.

Google’s Project Shield is now protecting KrebsOnSecurity.com
Why do I speak of DDoS attacks as a form of censorship? Quite simply because the economics of mitigating large-scale DDoS attacks do not bode well for protecting the individual user, to say nothing of independent journalists.

In an interview with The Boston Globe, Akamai executives said the attack — if sustained — likely would have cost the company millions of dollars. In the hours and days following my site going offline, I spoke with multiple DDoS mitigation firms. One offered to host KrebsOnSecurity for two weeks at no charge, but after that they said the same kind of protection I had under Akamai would cost between $150,000 and $200,000 per year.

Ask yourself how many independent journalists could possibly afford that kind of protection money? A number of other providers offered to help, but it was clear that they did not have the muscle to be able to withstand such massive attacks.

I’ve been toying with the idea of forming a 501(c)3 non-profit organization — ‘The Center for the Defense of Internet Journalism’, if you will — to assist Internet journalists with obtaining the kind of protection they may need when they become the targets of attacks like the one that hit my site.  Maybe a Kickstarter campaign, along with donations from well-known charitable organizations, could get the ball rolling.  It’s food for thought.

CALIBRATING THE CANNONS

Earlier this month, noted cryptologist and security blogger Bruce Schneier penned an unusually alarmist column titled, “Someone Is Learning How to Take Down the Internet.” Citing unnamed sources, Schneier warned that there was strong evidence indicating that nation-state actors were actively and aggressively probing the Internet for weak spots that could allow them to bring the entire Web to a virtual standstill.

“Someone is extensively testing the core defensive capabilities of the companies that provide critical Internet services,” Schneier wrote. “Who would do this? It doesn’t seem like something an activist, criminal, or researcher would do. Profiling core infrastructure is common practice in espionage and intelligence gathering. It’s not normal for companies to do that.”

Schneier continued:

“Furthermore, the size and scale of these probes — and especially their persistence — points to state actors. It feels like a nation’s military cyber command trying to calibrate its weaponry in the case of cyberwar. It reminds me of the US’s Cold War program of flying high-altitude planes over the Soviet Union to force their air-defense systems to turn on, to map their capabilities.”

Whether Schneier’s sources were accurate in their assessment of the actors referenced in his blog post is unknown. But as my friend and mentor Roland Dobbins at Arbor Networks eloquently put it, “When it comes to DDoS attacks, nation-states are just another player.”

“Today’s reality is that DDoS attacks have become the Great Equalizer between private actors & nation-states,” Dobbins quipped.

UM…YOUR RERUNS OF ‘SEINFELD’ JUST ATTACKED ME

What exactly was it that generated the record-smashing DDoS of 620 Gbps against my site this week? Was it a space-based weapon of mass disruption built and tested by a rogue nation-state, or an arch villain like SPECTRE from the James Bond series of novels and films? If only the enemy here was that black-and-white.

No, as I reported in the last blog post before my site was unplugged, the enemy in this case was far less sexy. There is every indication that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called “Internet of Things,” (IoT) devices — mainly routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords. Most of these devices are available for sale on retail store shelves for less than $100, or — in the case of routers — are shipped by ISPs to their customers.

Some readers on Twitter have asked why the attackers would have “burned” so many compromised systems with such an overwhelming force against my little site. After all, they reasoned, the attackers showed their hand in this assault, exposing the Internet addresses of a huge number of compromised devices that might otherwise be used for actual money-making cybercriminal activities, such as hosting malware or relaying spam. Surely, network providers would take that list of hacked devices and begin blocking them from launching attacks going forward, the thinking goes.

As KrebsOnSecurity reader Rob Wright commented on Twitter, “the DDoS attack on @briankrebs feels like testing the Death Star on the Millennium Falcon instead of Alderaan.” I replied that this maybe wasn’t the most apt analogy. The reality is that there are currently millions — if not tens of millions — of insecure or poorly secured IoT devices that are ripe for being enlisted in these attacks at any given time. And we’re adding millions more each year.

I suggested to Mr. Wright perhaps a better comparison was that ne’er-do-wells now have a virtually limitless supply of Stormtrooper clones that can be conscripted into an attack at a moment’s notice.

A scene from the 1977 movie Star Wars, in which the Death Star tests its firepower by blowing up a planet.

SHAMING THE SPOOFERS

The problem of DDoS conscripts goes well beyond the millions of IoT devices that are shipped insecure by default: Countless hosting providers and ISPs do nothing to prevent devices on their networks from being used by miscreants to “spoof” the source of DDoS attacks.

As I noted in a November 2015 story, The Lingering Mess from Default Insecurity, one basic step that many ISPs can but are not taking to blunt these attacks involves a network security standard that was developed and released more than a dozen years ago. Known as BCP38, its use prevents insecure resources on an ISPs network (hacked servers, computers, routers, DVRs, etc.) from being leveraged in such powerful denial-of-service attacks.

Using a technique called traffic amplification and reflection, the attacker can reflect his traffic from one or more third-party machines toward the intended target. In this type of assault, the attacker sends a message to a third party, while spoofing the Internet address of the victim. When the third party replies to the message, the reply is sent to the victim — and the reply is much larger than the original message, thereby amplifying the size of the attack.

BCP38 is designed to filter such spoofed traffic, so that it never even traverses the network of an ISP that’s adopted the anti-spoofing measures. However, there are non-trivial economic reasons that many ISPs fail to adopt this best practice. This blog post from the Internet Society does a good job of explaining why many ISPs ultimately decide not to implement BCP38.

Fortunately, there are efforts afoot to gather information about which networks and ISPs have neglected to filter out spoofed traffic leaving their networks. The idea is that by “naming and shaming” the providers who aren’t doing said filtering, the Internet community might pressure some of these actors into doing the right thing (or perhaps even offer preferential treatment to those providers who do conduct this basic network hygiene).

A research experiment by the Center for Applied Internet Data Analysis (CAIDA) called the “Spoofer Project” is slowly collecting this data, but it relies on users voluntarily running CAIDA’s software client to gather that intel. Unfortunately, a huge percentage of the networks that allow spoofing are hosting providers that offer extremely low-cost, virtual private servers (VPS). And these companies will never voluntarily run CAIDA’s spoof-testing tools.

CAIDA’s Spoofer Project page.
As a result, the biggest offenders will continue to fly under the radar of public attention unless and until more pressure is applied by hardware and software makers, as well as ISPs that are doing the right thing.

How might we gain a more complete picture of which network providers aren’t blocking spoofed traffic — without relying solely on voluntary reporting? That would likely require a concerted effort by a coalition of major hardware makers, operating system manufacturers and cloud providers, including Amazon, Apple, Google, Microsoft and entities which maintain the major Web server products (Apache, Nginx, e.g.), as well as the major Linux and Unix operating systems.

The coalition could decide that they will unilaterally build such instrumentation into their products. At that point, it would become difficult for hosting providers or their myriad resellers to hide the fact that they’re allowing systems on their networks to be leveraged in large-scale DDoS attacks.

To address the threat from the mass-proliferation of hardware devices such as Internet routers, DVRs and IP cameras that ship with default-insecure settings, we probably need an industry security association, with published standards that all members adhere to and are audited against periodically.

The wholesalers and retailers of these devices might then be encouraged to shift their focus toward buying and promoting connected devices which have this industry security association seal of approval. Consumers also would need to be educated to look for that seal of approval. Something like Underwriters Laboratories (UL), but for the Internet, perhaps.

THE BLEAK VS. THE BRIGHT FUTURE

As much as I believe such efforts could help dramatically limit the firepower available to today’s attackers, I’m not holding my breath that such a coalition will materialize anytime soon. But it’s probably worth mentioning that there are several precedents for this type of cross-industry collaboration to fight global cyber threats.

In 2008, the United States Computer Emergency Readiness Team (CERT) announced that researcher Dan Kaminsky had discovered a fundamental flaw in DNS that could allow anyone to intercept and manipulate most Internet-based communications, including email and e-commerce applications. A diverse community of software and hardware makers came together to fix the vulnerability and to coordinate the disclosure and patching of the design flaw.

In 2009, Microsoft heralded the formation of an industry group to collaboratively counter Conficker, a malware threat that infected tens of millions of Windows PCs and held the threat of allowing cybercriminals to amass a stupendous army of botted systems virtually overnight. A group of software and security firms, dubbed the Conficker Cabal, hashed out and executed a plan for corralling infected systems and halting the spread of Conficker.

In 2011, a diverse group of industry players and law enforcement organizations came together to eradicate the threat from the DNS Changer Trojan, a malware strain that infected millions of Microsoft Windows systems and enslaved them in a botnet that was used for large-scale cyber fraud schemes.

These examples provide useful templates for a solution to the DDoS problem going forward. What appears to be missing is any sense of urgency to address the DDoS threat on a coordinated, global scale.

That’s probably because at least for now, the criminals at the helm of these huge DDoS crime machines are content to use them to launch petty yet costly attacks against targets that suit their interests or whims.

For example, the massive 620 Gbps attack that hit my site this week was an apparent retaliation for a story I wrote exposing two Israeli men who were arrested shortly after that story ran for allegedly operating vDOS — until recently the most popular DDoS-for-hire network. The traffic hurled at my site in that massive attack included the text string “freeapplej4ck,” a reference to the hacker nickname used by one of vDOS’s alleged co-founders.

Most of the time, ne’er-do-wells like Applej4ck and others are content to use their huge DDoS armies to attack gaming sites and services. But the crooks maintaining these large crime machines haven’t just been targeting gaming sites. OVH, a major Web hosting provider based in France, said in a post on Twitter this week that it was recently the victim of an even more massive attack than hit my site. According to a Tweet from OVH founder Octave Klaba, that attack was launched by a botnet consisting of more than 145,000 compromised IP cameras and DVRs.

I don’t know what it will take to wake the larger Internet community out of its slumber to address this growing threat to free speech and ecommerce. My guess is it will take an attack that endangers human lives, shuts down critical national infrastructure systems, or disrupts national elections.

But what we’re allowing by our inaction is for individual actors to build the instrumentality of tyranny. And to be clear, these weapons can be wielded by anyone — with any motivation — who’s willing to expend a modicum of time and effort to learn the most basic principles of its operation.

The sad truth these days is that it’s a lot easier to censor the digital media on the Internet than it is to censor printed books and newspapers in the physical world. On the Internet, anyone with an axe to grind and the willingness to learn a bit about the technology can become an instant, self-appointed global censor.

I sincerely hope we can address this problem before it’s too late. And I’m deeply grateful for the overwhelming outpouring of support and solidarity that I’ve seen and heard from so many readers over the past few days. Thank you.
Top

mupdf: mujstest: global-buffer-overflow in main (jstest_main.c)

Postby ago via agostino's blog »

Description:
Mujstest, which is part of mupdf is a scriptable tester for mupdf + js.

A fuzzing revealed a global buffer overflow write.

The complete ASan output:

# mujstest $FILE
=================================================================
==2244==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000013c6140 at pc 0x000000473526 bp 0x7fff866f77d0 sp 0x7fff866f6f80
WRITE of size 1181 at 0x0000013c6140 thread T0
    #0 0x473525 in __interceptor_strcpy /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:547
    #1 0x4f7910 in main /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/platform/x11/jstest_main.c:353:6
    #2 0x7f3a6c18661f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #3 0x41ade8 in _init (/usr/bin/mujstest+0x41ade8)

0x0000013c6140 is located 0 bytes to the right of global variable 'filename' defined in 'platform/x11/jstest_main.c:15:13' (0x13c5d40) of size 1024
SUMMARY: AddressSanitizer: global-buffer-overflow /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:547 in __interceptor_strcpy
Shadow bytes around the buggy address:
  0x000080270bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270be0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x000080270c20: 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9 f9
  0x000080270c30: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080270c40: f9 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x000080270c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2244==ABORTING
Affected version:
1.9a

Fixed version:
2.0 (not yet released)

Commit fix:
http://git.ghostscript.com/?p=mupdf.git;h=cfe8f35bca61056363368c343be36812abde0a06

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-04: bug discovered
2016-08-05: bug reported to upstream
2016-09-22: upstream released a patch
2016-09-24: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

mupdf: mujstest: global-buffer-overflow in main (jstest_main.c)

Top

mupdf: mujstest: global-buffer-overflow in my_getline (jstest_main.c)

Postby ago via agostino's blog »

Description:
Mujstest, which is part of mupdf is a scriptable tester for mupdf + js.

A fuzzing revealed a global buffer overflow write.

The complete ASan output:

# mujstest $FILE
==1278==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0000013c7280 at pc 0x0000004fa432 bp 0x7ffea75837d0 sp 0x7ffea75837c8
WRITE of size 1 at 0x0000013c7280 thread T0
    #0 0x4fa431 in my_getline /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/platform/x11/jstest_main.c:214:5
    #1 0x4fa431 in main /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/platform/x11/jstest_main.c:335
    #2 0x7fb62229661f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #3 0x41ade8 in _init (/usr/bin/mujstest+0x41ade8)

0x0000013c7280 is located 0 bytes to the right of global variable 'getline_buffer' defined in 'platform/x11/jstest_main.c:24:13' (0x13c6280) of size 4096
SUMMARY: AddressSanitizer: global-buffer-overflow /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/platform/x11/jstest_main.c:214:5 in my_getline
Shadow bytes around the buggy address:
  0x000080270e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270e10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270e30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080270e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x000080270e50:[f9]f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080270e60: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080270e70: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080270e80: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080270e90: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080270ea0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1278==ABORTING
Affected version:
1.9a

Fixed version:
2.0 (not yet released)

Commit fix:
http://git.ghostscript.com/?p=mupdf.git;h=446097f97b71ce20fa8d1e45e070f2e62676003e

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-04: bug discovered
2016-08-05: bug reported to upstream
2016-09-22: upstream released a patch
2016-09-24: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

mupdf: mujstest: global-buffer-overflow in my_getline (jstest_main.c)

Top

Few notes on locale craziness

Postby Michał Górny via Michał Górny »

Back in the EAPI 6 guide I shortly noted that we have added a sanitization requirement for locales. Having been informed of another locale issue in Python (pre-EAPI 6 ebuild), I have decided to write a short note of locale curiosities that could also serve in reporting issues upstream.

When l10n and i18n are concerned, most of the developers correctly predict that the date and time format, currencies, number formats are going to change. It’s rather hard to find an application that would fail because of changed system date format; however, much easier to find one that does not respect the locale and uses hard-coded format strings for user display. You can find applications that unconditionally use a specific decimal separator but it’s quite rare to find one that chokes itself combining code using hard-coded separator and system routines respecting locales. Some applications rely on English error messages but that’s rather obviously perceived as mistake. However, there are also two hard cases…



Lowercase and uppercase

For a start, if you thought that the ASCII range of lowercase characters would map clearly to the ASCII range of uppercase characters, you were wrong. The Turkish (tr_TR) locale is different here, and maps lowercase ‘i’ (LATIN SMALL LETTER I) into uppercase ‘İ’ (LATIN CAPITAL LETTER I WITH DOT ABOVE). Similarly, ‘I’ (LATIN CAPITAL LETTER I) maps to ‘ı’ (LATIN SMALL LETTER DOTLESS I). What does this mean in practice? That if you have a Turkish user, then depending on the software used, you Latin ‘i’ may be uppercased onto ‘I’ (as you expect it to be), ‘İ’ (as would be correct in free text) or… left as ‘i’.

What’s the solution for this? If you need to uppercase/lowercase an ASCII text (e.g. variable names), either use a function that does not respect locale (e.g. 'i' - ('a' - 'A') in C) or set LC_CTYPE to a sane locale (e.g. C). However, remember that LC_CTYPE affects the character encoding — i.e. if you read UTF-8, you need to use a locale with UTF-8 codeset.

Collation

The other problem is collation, i.e. sorting. The more obvious part of it is that the particular locales enforce specific sorting of their specific diacritic characters. For example, the Polish letter ‘ą’ would be sorted between ‘a’ and ‘b’ in the Polish locale, and somewhere at the end in the C locale. The intermediately obvious part of it is that some locales have different ordering of lowercase and uppercase characters — the C and German locales sort uppercase characters first (the former because of ASCII codes), while many other locales sort the opposite.

Now, the non-obvious part is that some locales actually reorder the Latin alphabet. For example, the Estonian (et_EE) locale puts ‘z’ somewhere between ‘s’ and ‘t’. Yep, seriously. What’s even less obvious is that it means that the [a-z] character class suddenly ends halfway through the lowercase characters!

What’s the solution? Again, either use non-locale-sensitive functions or sanitize LC_COLLATE. For regular expressions, the named character classes ([[:lower:]], [[:upper:]]) are always a better choice.

Does anyone know more fun locales?
Top

mupdf: use-after-free in pdf_to_num (pdf-object.c)

Postby ago via agostino's blog »

Description:
mupdf is a lightweight PDF viewer and toolkit written in portable C.

A fuzzing through mutool revealed a use-after-free.

The complete ASan output:

# mutool info $FILE
==5430==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000ea42 at pc 0x7fbc4c3824e5 bp 0x7ffee68ead70 sp 0x7ffee68ead68                                                                                                                                       
READ of size 1 at 0x60300000ea42 thread T0                                                                                                                                                                                                                                    
    #0 0x7fbc4c3824e4 in pdf_to_num /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-object.c:375:35                                                                                                                                                       
    #1 0x53f042 in gatherfonts /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:259:46                                                                                                                                                             
    #2 0x53f042 in gatherresourceinfo /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:595                                                                                                                                                         
    #3 0x53913a in gatherpageinfo /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:661:2                                                                                                                                                           
    #4 0x53913a in showinfo /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:957                                                                                                                                                                   
    #5 0x537d46 in pdfinfo_info /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:1029:3                                                                                                                                                            
    #6 0x537d46 in pdfinfo_main /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:1077                                                                                                                                                              
    #7 0x4f8ace in main /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/mutool.c:104:12                                                                                                                                                                     
    #8 0x7fbc4ae1f61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                                                                                                       
    #9 0x41f9c8 in _init (/usr/bin/mutool+0x41f9c8)                                                                                                                                                                                                                           
                                                                                                                                                                                                                                                                              
0x60300000ea42 is located 2 bytes inside of 24-byte region [0x60300000ea40,0x60300000ea58)                                                                                                                                                                                    
freed by thread T0 here:                                                                                                                                                                                                                                                      
    #0 0x4c6c10 in free /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:38                                                                                                                                    
    #1 0x7fbc4bf33830 in fz_free /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/fitz/memory.c:187:2                                                                                                                                                              
                                                                                                                                                                                                                                                                              
previously allocated by thread T0 here:                                                                                                                                                                                                                                       
    #0 0x4c6f18 in malloc /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52                                                                                                                                  
    #1 0x7fbc4bf2a86f in do_scavenging_malloc /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/fitz/memory.c:17:7                                                                                                                                                  
    #2 0x7fbc4bf2a86f in fz_malloc /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/fitz/memory.c:57                                                                                                                                                               
    #3 0x7fbc4c37f94d in pdf_new_indirect /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-object.c:186:8                                                                                                                                                  
                                                                                                                                                                                                                                                                              
SUMMARY: AddressSanitizer: heap-use-after-free /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-object.c:375:35 in pdf_to_num                                                                                                                              
Shadow bytes around the buggy address:                                                                                                                                                                                                                                        
  0x0c067fff9cf0: fd fd fa fa fd fd fd fa fa fa fd fd fd fa fa fa                                                                                                                                                                                                             
  0x0c067fff9d00: fd fd fd fd fa fa fd fd fd fa fa fa fd fd fd fa                                                                                                                                                                                                             
  0x0c067fff9d10: fa fa fd fd fd fd fa fa fd fd fd fa fa fa fd fd                                                                                                                                                                                                             
  0x0c067fff9d20: fd fa fa fa fd fd fd fd fa fa fd fd fd fa fa fa
  0x0c067fff9d30: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
=>0x0c067fff9d40: fa fa 00 00 00 fa fa fa[fd]fd fd fa fa fa fd fd
  0x0c067fff9d50: fd fd fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
  0x0c067fff9d60: 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 00 fa
  0x0c067fff9d70: fa fa 00 00 00 fa fa fa 00 00 00 06 fa fa 00 00
  0x0c067fff9d80: 01 fa fa fa 00 00 05 fa fa fa 00 00 00 fa fa fa
  0x0c067fff9d90: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==5430==ABORTING
Affected version:
1.9a

Fixed version:
1.10 (not yet released)

Commit fix:
http://git.ghostscript.com/?p=mupdf.git;h=1e03c06456d997435019fb3526fa2d4be7dbc6ec

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:

Timeline:
2016-08-05: bug discovered
2016-08-05: bug reported privately to upstream
2016-09-22: upstream released a patch
2016-09-22: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

mupdf: use-after-free in pdf_to_num (pdf-object.c)

Top

mupdf: mutool: infinite loop in gatherresourceinfo (pdfinfo.c)

Postby ago via agostino's blog »

Description:
mupdf is a lightweight PDF viewer and toolkit written in portable C.

A fuzzing through mutool revealed an infinite loop in gatherresourceinfo if mutool tries to get info from a crafted pdf.

The output is a bit cutted because the original is ~1300 lines (because of the loop)

# mutool info $FILE
[cut here]
warning: not a font dict (0 0 R)
ASAN:DEADLYSIGNAL
=================================================================
==8763==ERROR: AddressSanitizer: stack-overflow on address 0x7ffeb34e6f6c (pc 0x7f188e685b2e bp 0x7ffeb34e7410 sp 0x7ffeb34e6ea0 T0)
    #0 0x7f188e685b2d in _IO_vfprintf /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/stdio-common/vfprintf.c:1266
    #1 0x7f188e6888c0 in buffered_vfprintf /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/stdio-common/vfprintf.c:2346
    #2 0x7f188e685cd4 in _IO_vfprintf /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/stdio-common/vfprintf.c:1292
    #3 0x49927f in __interceptor_vfprintf /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1111
    #4 0x499352 in fprintf /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1156
    #5 0x7f188f70f03c in fz_flush_warnings /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/fitz/error.c:18:3
    #6 0x7f188f70f03c in fz_throw /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/fitz/error.c:168
    #7 0x7f188fac98d5 in pdf_parse_ind_obj /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-parse.c:565:3
    #8 0x7f188fb5fe6b in pdf_cache_object /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-xref.c:2029:13
    #9 0x7f188fb658d2 in pdf_resolve_indirect /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-xref.c:2155:12
    #10 0x7f188fbc0a0d in pdf_is_dict /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/pdf/pdf-object.c:268:2
    #11 0x53ea6a in gatherfonts /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:257:8
    #12 0x53ea6a in gatherresourceinfo /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:595
    #13 0x53f31b in gatherresourceinfo /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:603:5
    [cut here]
    #253 0x53f31b in gatherresourceinfo /var/tmp/portage/app-text/mupdf-1.9a/work/mupdf-1.9a/source/tools/pdfinfo.c:603:5

SUMMARY: AddressSanitizer: stack-overflow /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/stdio-common/vfprintf.c:1266 in _IO_vfprintf
==8763==ABORTING
1152.crashes:
PDF-1.4
Pages: 1
Retrieving info from pages 1-1...
Affected version:
1.9a

Fixed version:
1.10 (not yet released)

Commit fix:
http://git.ghostscript.com/?p=mupdf.git;h=fdf71862fe929b4560e9f632d775c50313d6ef02

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

Timeline:
2016-08-05: bug discovered
2016-08-05: bug reported to upstream
2016-09-22: upstream released a patch
2016-09-22: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

mupdf: mutool: infinite loop in gatherresourceinfo (pdfinfo.c)

Top

KrebsOnSecurity Hit With Record DDoS

Postby BrianKrebs via Krebs on Security »

On Tuesday evening, KrebsOnSecurity.com was the target of an extremely large and unusual distributed denial-of-service (DDoS) attack designed to knock the site offline. The attack did not succeed thanks to the hard work of the engineers at Akamai, the company that protects my site from such digital sieges. But according to Akamai, it was nearly double the size of the largest attack they’d seen previously, and was among the biggest assaults the Internet has ever witnessed.


The attack began around 8 p.m. ET on Sept. 20, and initial reports put it at approximately 665 Gigabits of traffic per second. Additional analysis on the attack traffic suggests the assault was closer to 620 Gbps in size, but in any case this is many orders of magnitude more traffic than is typically needed to knock most sites offline.

Martin McKeay, Akamai’s senior security advocate, said the largest attack the company had seen previously clocked in earlier this year at 363 Gbps. But he said there was a major difference between last night’s DDoS and the previous record holder: The 363 Gpbs attack is thought to have been generated by a botnet of compromised systems using well-known techniques allowing them to “amplify” a relatively small attack into a much larger one.

In contrast, the huge assault this week on my site appears to have been launched almost exclusively by a very large botnet of hacked devices.

The largest DDoS attacks on record tend to be the result of a tried-and-true method known as a DNS reflection attack. In such assaults, the perpetrators are able to leverage unmanaged DNS servers on the Web to create huge traffic floods.

Ideally, DNS servers only provide services to machines within a trusted domain. But DNS reflection attacks rely on consumer and business routers and other devices equipped with DNS servers that are (mis)configured to accept queries from anywhere on the Web. Attackers can send spoofed DNS queries to these so-called “open recursive” DNS servers, forging the request so that it appears to come from the target’s network. That way, when the DNS servers respond, they reply to the spoofed (target) address.

The bad guys also can amplify a reflective attack by crafting DNS queries so that the responses are much bigger than the requests. They do this by taking advantage of an extension to the DNS protocol that enables large DNS messages. For example, an attacker could compose a DNS request of less than 100 bytes, prompting a response that is 60-70 times as large. This “amplification” effect is especially pronounced if the perpetrators query dozens of DNS servers with these spoofed requests simultaneously.

But according to Akamai, none of the attack methods employed in Tuesday night’s assault on KrebsOnSecurity relied on amplification or reflection. Rather, many were garbage Web attack methods that require a legitimate connection between the attacking host and the target, including SYN, GET and POST floods.

That is, with the exception of one attack method: Preliminary analysis of the attack traffic suggests that perhaps the biggest chunk of the attack came in the form of traffic designed to look like it was generic routing encapsulation (GRE) data packets, a communication protocol used to establish a direct, point-to-point connection between network nodes. GRE lets two peers share data they wouldn’t be able to share over the public network itself.

“Seeing that much attack coming from GRE is really unusual,” Akamai’s McKeay said. “We’ve only started seeing that recently, but seeing it at this volume is very new.”

McKeay explained that the source of GRE traffic can’t be spoofed or faked the same way DDoS attackers can spoof DNS traffic. Nor can junk Web-based DDoS attacks like those mentioned above. That suggests the attackers behind this record assault launched it from quite a large collection of hacked systems — possibly hundreds of thousands of systems.

“Someone has a botnet with capabilities we haven’t seen before,” McKeay said. “We looked at the traffic coming from the attacking systems, and they weren’t just from one region of the world or from a small subset of networks — they were everywhere.”

There are some indications that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called “Internet of Things,” (IoT) devices — routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords.

As noted in a recent report from Flashpoint and Level 3 Threat Research Labs, the threat from IoT-based botnets is powered by malware that goes by many names, including “Lizkebab,” “BASHLITE,” “Torlus” and “gafgyt.” According to that report, the source code for this malware was leaked in early 2015 and has been spun off into more than a dozen variants.

“Each botnet spreads to new hosts by scanning for vulnerable devices in order to install the malware,” the report notes. “Two primary models for scanning exist. The first instructs bots to port scan for telnet servers and attempts to brute force the username and password to gain access to the device.”

Their analysis continues:

“The other model, which is becoming increasingly common, uses external scanners to find and harvest new bots, in some cases scanning from the [botnet control] servers themselves. The latter model adds a wide variety of infection methods, including brute forcing login credentials on SSH servers and exploiting known security weaknesses in other services.”

I’ll address some of the challenges of minimizing the threat from large-scale DDoS attacks in a future post. But for now it seems likely that we can expect such monster attacks to soon become the new norm.

Many readers have been asking whether this attack was in retaliation for my recent series on the takedown of the DDoS-for-hire service vDOS, which coincided with the arrests of two young men named in my original report as founders of the service.

I can’t say for sure, but it seems likely related: Some of the POST request attacks that came in last night as part of this 620 Gbps attack included the string “freeapplej4ck,” a reference to the nickname used by one of the vDOS co-owners.

Update Sept. 22, 8:33 a.m. ET: Corrected the maximum previous DDoS seen by Akamai. It was 363, not 336 as stated earlier.
Top

libav: divide-by-zero in sbr_make_f_master (aacsbr.c)

Postby ago via agostino's blog »

Description:
Libav is an open source set of tools for audio and video processing.

A fuzzing with an mp3 file as input discovered a divide-by-zero in sbr_make_f_master.

The complete ASan output:

# avconv -i $FILE -f null -
avconv version 11.7, Copyright (c) 2000-2016 the Libav developers
  built on Aug 16 2016 15:34:42 with clang version 3.8.1 (tags/RELEASE_381/final)
[mpeg @ 0x61a00001f280] Format detected only with low score of 25, misdetection possible!
[aac @ 0x619000000580] Sample rate index in program config element does not match the sample rate index configured by the container.
[aac @ 0x619000000580] SBR was found before the first channel element.
ASAN:DEADLYSIGNAL
=================================================================
==29103==ERROR: AddressSanitizer: FPE on unknown address 0x7fbd80295491 (pc 0x7fbd80295491 bp 0x7ffde63eb2f0 sp 0x7ffde63eafa0 T0)
    #0 0x7fbd80295490 in sbr_make_f_master /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacsbr.c:338:57
    #1 0x7fbd80295490 in sbr_reset /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacsbr.c:1045
    #2 0x7fbd80295490 in ff_decode_sbr_extension /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacsbr.c:1093
    #3 0x7fbd801efe1b in decode_extension_payload /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacdec.c:2196:15
    #4 0x7fbd801efe1b in aac_decode_frame_int /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacdec.c:2866
    #5 0x7fbd801d3bbb in aac_decode_frame /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacdec.c:2959:15
    #6 0x7fbd823ed42a in avcodec_decode_audio4 /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/utils.c:1657:15
    #7 0x7fbd83f00b20 in try_decode_frame /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavformat/utils.c:1914:19
    #8 0x7fbd83ef76e2 in avformat_find_stream_info /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavformat/utils.c:2276:9
    #9 0x50d195 in open_input_file /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv_opt.c:726:11
    #10 0x50b625 in open_files /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv_opt.c:2127:15
    #11 0x50af81 in avconv_parse_options /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv_opt.c:2164:11
    #12 0x541414 in main /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2630:11
    #13 0x7fbd7e77f61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #14 0x41d098 in _init (/usr/bin/avconv+0x41d098)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/aacsbr.c:338:57 in sbr_make_f_master
==29103==ABORTING
Affected version:
11.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-7499

Timeline:
2016-08-15: bug discovered
2016-08-16: bug reported to upstream
2016-09-21: blog post about the issue
2016-09-21: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libav: divide-by-zero in sbr_make_f_master (aacsbr.c)

Top

DDoS Mitigation Firm Has History of Hijacks

Postby BrianKrebs via Krebs on Security »

Last week, KrebsOnSecurity detailed how BackConnect Inc. — a company that defends victims against large-scale distributed denial-of-service (DDoS) attacks — admitted to hijacking hundreds of Internet addresses from a European Internet service provider in order to glean information about attackers who were targeting BackConnect. According to an exhaustive analysis of historic Internet records, BackConnect appears to have a history of such “hacking back” activity.

On Sept. 8, 2016, KrebsOnSecurity exposed the inner workings of vDOS, a DDoS-for-hire or “booter” service whose tens of thousands of paying customers used the service to launch attacks against hundreds of thousands of targets over the service’s four-year history in business.

vDOS as it existed on Sept. 8, 2016.
Within hours of that story running, the two alleged owners — 18-year-old Israeli men identified in the original report — were arrested in Israel in connection with an FBI investigation into the shady business, which earned well north of $600,000 for the two men.

In my follow-up report on their arrests, I noted that vDOS itself had gone offline, and that automated Twitter feeds which report on large-scale changes to the global Internet routing tables observed that vDOS’s provider — a Bulgarian host named Verdina[dot]net — had been briefly relieved of control over 255 Internet addresses (including those assigned to vDOS) as the direct result of an unusual counterattack by BackConnect.

Asked about the reason for the counterattack, BackConnect CEO Bryant Townsend confirmed to this author that it had executed what’s known as a “BGP hijack.” In short, the company had fraudulently “announced” to the rest of the world’s Internet service providers (ISPs) that it was the rightful owner of the range of those 255 Internet addresses at Verdina occupied by vDOS.

In a post on NANOG Sept. 13, BackConnect’s Townsend said his company took the extreme measure after coming under a sustained DDoS attack thought to have been launched by a botnet controlled by vDOS. Townsend explained that the hijack allowed his firm to “collect intelligence on the actors behind the botnet as well as identify the attack servers used by the booter service.”

Short for Border Gateway Protocol, BGP is a mechanism by which ISPs of the world share information about which providers are responsible for routing Internet traffic to specific addresses. However, like most components built into the modern Internet, BGP was never designed with security in mind, which leaves it vulnerable to exploitation by rogue actors.

BackConnect’s BGP hijack of Verdina caused quite an uproar among many Internet technologists who discuss such matters at the mailing list of the North American Network Operators Group (NANOG).

BGP hijacks are hardly unprecedented, but when they are non-consensual they are either done accidentally or are the work of cyber criminals such as spammers looking to hijack address space for use in blasting out junk email. If BackConnect’s hijacking of Verdina was an example of a DDoS mitigation firm “hacking back,” what would discourage others from doing the same, they wondered?

“Once we let providers cross the line from legal to illegal actions, we’re no better than the crooks, and the Internet will descend into lawless chaos,” wrote Mel Beckman, owner of Beckman Software Engineering and a computer networking consultant in the Los Angeles area. “BackConnect’s illicit action undoubtedly injured innocent parties, so it’s not self defense, any more than shooting wildly into a crowd to stop an attacker would be self defense.”

A HISTORY OF HIJACKS

Townsend’s explanation seemed to produce more questions than answers among the NANOG crowd (read the entire “Defensive BGP Hijacking” thread here if you dare). I grew more curious to learn whether this was a pattern for BackConnect when I started looking deeper into the history of two young men who co-founded BackConnect (more on them in a bit).

To get a better picture of BackConnect’s history, I turned to BGP hijacking expert Doug Madory, director of Internet analysis at Dyn, a cloud-based Internet performance management company. Madory pulled historic BGP records for BackConnect, and sure enough a strange pattern began to emerge.

Madory was careful to caution up front that not all BGP hijacks are malicious. Indeed, my DDoS protection provider — a company called Prolexic Communications (now owned by Akamai Technologies) — practically invented the use of BGP hijacks as a DDoS mitigation method, he said.

In such a scenario, an organization under heavy DDoS attack might approach Prolexic and ask for assistance. With the customer’s permission, Prolexic would use BGP to announce to the rest of the world’s ISPs that it was now the rightful owner of the Internet addresses under attack. This would allow Prolexic to “scrub” the customer’s incoming Web traffic to drop data packets designed to knock the customer offline — and forward the legitimate traffic on to the customer’s site.

Given that BackConnect is also a DDoS mitigation company, I asked Madory how one could reasonably tell the difference between a BGP hijack that BackConnect had launched to protect a client versus one that might have been launched for other purposes — such as surreptitiously collecting intelligence on DDoS-based botnets and their owners?

Madory explained that in evaluating whether a BGP hijack is malicious or consensual, he looks at four qualities: The duration of the hijack; whether it was announced globally or just to the target ISP’s local peers; whether the hijacker took steps to obfuscate which ISP was doing the hijacking; and whether the hijacker and hijacked agreed upon the action.



For starters, malicious BGP attacks designed to gather information about an attacking host are likely to be very brief — often lasting just a few minutes. The brevity of such hijacks makes them somewhat ineffective at mitigating large-scale DDoS attacks, which often last for hours at a time. For example, the BGP hijack that BackConnect launched against Verdina lasted a fraction of an hour, and according to the company’s CEO was launched only after the DDoS attack subsided.

Second, if the party conducting the hijack is doing so for information gathering purposes, that party may attempt to limit the number ISPs that receive the new routing instructions. This might help an uninvited BGP hijacker achieve the end result of intercepting traffic to and from the target network without informing all of the world’s ISPs simultaneously.

“If a sizable portion of the Internet’s routers do not carry a route to a DDoS mitigation provider, then they won’t be sending DDoS traffic destined for the corresponding address space to the provider’s traffic scrubbing centers, thus limiting the efficacy of any mitigation,” Madory wrote in his own blog post about our joint investigation.

Thirdly, a BGP hijacker who is trying not to draw attention to himself can “forge” the BGP records so that it appears that the hijack was performed by another party. Madory said this forgery process often fools less experienced investigators, but that ultimately it is impossible to hide the true origin of forged BGP records.

Finally, in BGP hijacks that are consensual for DDoS mitigation purposes, the host under attack stops “announcing” to the world’s ISPs that it is the rightful owner of an address block under siege at about the same time the DDoS mitigation provider begins claiming it. When we see BGP hijacks in which both parties are claiming in the BGP records to be authoritative for a given swath of Internet addresses, Madory said, it’s less likely that the BGP hijack is consensual.

Madory and KrebsOnSecurity spent several days reviewing historic records of BGP hijacks attributed to BackConnect over the past year, and at least three besides the admitted hijack against Verdina strongly suggest that the company has engaged in this type of intel-gathering activity previously. The strongest indicator of a malicious and non-consensual BGP hijack, Madory said, were the ones that included forged BGP records.

Working together, Madory and KrebsOnSecurity identified at least 17 incidents during that time frame that were possible BGP hijacks conducted by BackConnect. Of those, five included forged BGP records. One was an hours-long hijack against Ghostnet[dot]de, a hosting provider in Germany.

Two other BGP hijacks from BackConnect that included spoofed records were against Staminus Communications, a competing DDoS mitigation provider and a firm that employed BackConnect CEO Townsend for three years as senior vice president of business development until his departure from Staminus in December 2015.

“This hijack wasn’t conducted by Staminus. It was BackConnect posing as Staminus,” Dyn’s Madory concluded.

Two weeks after BackConnect hijacked the Staminus routes, Staminus was massively hacked. Unknown attackers, operating under the banner “Fuck ‘Em All,” reset all of the configurations on the company’s Internet routers, and then posted online Staminus’s customer credentials, support tickets, credit card numbers and other sensitive data. The intruders also posted to Pastebin a taunting note ridiculing the company’s security practices.

BackConnect’s apparent hijack of address space owned by Staminus Communications on Feb. 20, 2016. Image: Dyn.

POINTING FINGERS

I asked Townsend to comment on the BGP hijacks identified by KrebsOnSecurity and Dyn as having spoofed source information. Townsend replied that he could not provide any insight as to why these incidents occurred, noting that he and the company’s chief technology officer — 24-year-old Marshal Webb — only had access and visibility into the network after the company BackConnect Inc. was created on April 27, 2016.

According to Townsend, the current BackConnect Inc. is wholly separate from BackConnect Security LLC, which is a company started in 2014 by two young men: Webb and a 19-year-old security professional named Tucker Preston. In April 2016, Preston was voted out of the company by Webb and Townsend and forced to sell his share of the company, which was subsequently renamed BackConnect Inc.

“Before that, the original owner of BackConnect Security LLC was the only one that had the ability to access servers and perform any type of networking commands,” he explained. “We had never noticed these occurred until this last Saturday and the previous owner never communicated anything regarding these hijacks. Wish I could provide more insight, but Marshal and I do not know the reasons behind the previous owners decision to hijack those ranges or what he was trying to accomplish.”

In a phone interview, Preston told KrebsOnSecurity that Townsend had little to no understanding about the technical side of the business, and was merely “a sales guy” for BackConnect. He claims that Webb absolutely had and still has the ability to manipulate BackConnect’s BGP records and announcements.

Townsend countered that Preston was the only network engineer at the company.

“We had to self-learn how to do anything network related once the new company was founded and Tucker removed,” he said. “Marshal and myself didn’t even know how to use BGP until we were forced to learn it in order to bring on new clients. To clarify further, Marshal did not have a networking background and had only been working on our web panel and DDoS mitigation rules.”

L33T, LULZ, W00W00 AND CHIPPY

Preston said he first met Webb in 2013 after the latter admitted to launching DDoS attacks against one of Preston’s customers at the time. Webb had been painted with a somewhat sketchy recent history at the time — being fingered as a low-skilled hacker who went by the nicknames “m_nerva” and “Chippy1337.”

Webb, whose Facebook alias is “lulznet,” was publicly accused in 2011 by the hacker group LulzSec of snitching on the activities of the group to the FBI, claiming that information he shared with law enforcement led to the arrest of a teen hacker in England associated with LulzSec. Webb has publicly denied being an informant for the FBI, but did not respond to requests for comment on this story.

LulzSec members claimed that Webb was behind the hacking of the Web site for the video game “Deus Ex.” As KrebsOnSecurity noted in a story about the Deus Ex hack, the intruder defaced the gaming site with the message “Owned by Chippy1337.”

The defacement message left on deusex.com.
I was introduced to Webb at the Defcon hacking convention in Las Vegas in 2014. Since then, I have come to know him a bit more as a participant of w00w00, an invite-only Slack chat channel populated mainly by information security professionals who work in the DDoS mitigation business. Webb chose the handle Chippy1337 for his account in that Slack channel.

At the time, Webb was trying to convince me to take another look at Voxility, a hosting provider that I’ve previously noted has a rather checkered history and one that BackConnect appears to rely upon exclusively for its own hosting.

In our examination of BGP hijacks attributed to BackConnect, Dyn and KrebsOnSecurity identified an unusual incident in late July 2016 in which BackConnect could be seen hijacking an address range previously announced by Datawagon, a hosting provider with a rather dodgy reputation for hosting spammers and DDoS-for-hire sites.

That address range previously announced by Datawagon included the Internet address 1.3.3.7, which is hacker “leet speak” for the word “leet,” or “elite.” Interestingly, on the w00w00 DDoS discussion Slack channel I observed Webb (Chippy1337) offering other participants in the channel vanity addresses and virtual private connections (VPNs) ending in 1.3.3.7. In the screen shot below, Webb can be seen posting a screen shot demonstrating his access to the 1.3.3.7 address while logged into it on his mobile phone.

Webb, logged into the w00w00 DDoS discussion channel using his nickname “chippy1337,” demonstrating that his mobile phone connection was being routed through the Internet address 1.3.3.7, which BackConnect BGP hijacked in July 2016.

THE MONEY TEAM

The Web address 1.3.3.7 currently does not respond to browser requests, but it previously routed to a page listing the core members of a hacker group calling itself the Money Team. Other sites also previously tied to that Internet address include numerous DDoS-for-hire services, such as nazistresser[dot]biz, exostress[dot]in, scriptkiddie[dot]eu, packeting[dot]eu, leet[dot]hu, booter[dot]in, vivostresser[dot]com, shockingbooter[dot]com and xboot[dot]info, among others.

The Money Team comprised a group of online gaming enthusiasts of the massively popular game Counterstrike, and the group’s members specialized in selling cheats and hacks for the game, as well as various booter services that could be used to knock rival gamers offline.

Datawagon’s founder is an 18-year-old American named CJ Sculti whose 15-minutes of fame came last year in a cybersquatting dispute after he registered the domain dominos.pizza. A cached version of the Money Team’s home page saved by Archive.org lists CJ at the top of the member list, with “chippy1337” as the third member from the top.

The MoneyTeam’s roster as of November 2015. Image: Archive.org.
Asked why he chose to start a DDoS mitigation company with a kid who was into DDoS attacks, Preston said he got to know Webb over several years before teaming up with him to form BackConnect LLC.

“We were friends long before we ever started the company together,” Preston said. “I thought Marshal had turned over a new leaf and had moved away from all that black hat stuff. He seem to stay true to that until we split and he started getting involved with the Datawagon guys. I guess his lulz mentality came back in a really stupid way.”

Townsend said Webb was never an FBI informant, and was never arrested for involvement with LulzSec.

“Only a search warrant was executed at his residence,” Townsend said. “Chippy is not a unique handle to Marshal and it has been used by many people. Just because he uses that handle today doesn’t mean any past chippy actions are his doing. Marshal did not even go by Chippy when LulzSec was in the news. These claims are completely fabricated.”

As for the apparent Datawagon hijack, Townsend said Datawagon gave BackConnect permission to announce the company’s Internet address space but later decided not to become a customer.

“They were going to be a client and they gave us permission to announce that IP range via an LOA [letter of authorization]. They did not become a client and we removed the announcement. Also note that the date of the screen shot you present of Marshal talking about the 1.3.3.7. is not even the same as when we announced Datawagons IPs.”

SOMETHING SMELLS BAD

When vDOS was hacked, its entire user database was leaked to this author. Among the more active users of vDOS in 2016 was a user who went by the username “pp412” and who registered in February 2016 using the email address mn@gnu.so.

The information about who originally registered the gnu.so domain has long been hidden behind WHOIS privacy records. But for several months in 2015 and 2016 the registration records show it was registered to a Tucker Preston LLC. Preston denies that he ever registered the gnu.so domain, and claims that he never conducted any booter attacks via vDOS. However, Preston also was on the w00w00 Slack channel along with Webb, and registered there using the email address tucker@gnu.so.

But whoever owned that pp412 account at vDOS was active in attacking a large number of targets, including multiple assaults on networks belonging to the Free Software Foundation (FSF).

Logs from the hacked vDOS attack database show the user pp4l2 attacked the Free Software Foundation in May 2016.
Lisa Marie Maginnis, until very recently a senior system administrator at the FSF, said the foundation began evaluating DDoS mitigation providers in the months leading up to its LibrePlanet2016 conference in the third week of March. The organization had never suffered any real DDoS attacks to speak of previously, but NSA whistleblower Edward Snowden was slated to speak at the conference, and the FSF was concerned that someone might launch a DDoS attack to disrupt the streaming of Snowden’s keynote.

“We were worried this might bring us some extra unwanted attention,” she said.

Maginnis said the FSF had looked at BackConnect and other providers, but that it ultimately decided it didn’t have time to do the testing and evaluation required to properly vet a provider prior to the conference. So the organization tabled that decision. As it happened, the Snowden keynote was a success, and the FSF’s fears of a massive DDoS never materialized.

But all that changed in the weeks following the conference.

“The first attack we got started off kind of small, and it came around 3:30 on a Friday morning,” Maginnis recalled. “The next Friday at about the same time we were hit again, and then the next and the next.”

The DDoS attacks grew bigger with each passing week, she said, peaking at more than 200 Gbps — more than enough to knock large hosting providers offline, let alone individual sites like the FSF’s. When the FSF’s Internet provider succeeded in blacklisting the addresses doing the attacking, the attackers switched targets and began going after larger-scale ISPs further upstream.

“That’s when our ISP told us we had to do something because the attacks were really starting to impact the ISP’s other customers,” Maginnis said. “Routing all of our traffic through another company wasn’t exactly an ideal situation for the FSF, but the other choice was we would just be disconnected and there would be no more FSF online.”

In August, the FSF announced that it had signed up with BackConnect to be protected from DDoS attacks, in part because the foundation only uses free software to perform its work, and BackConnect advertises “open source DDoS protection and security,” and it agreed to provide the service without charge.

The FSF declined to comment for this story. Maginnis said she can’t be sure whether the foundation will continue to work with BackConnect. But she said the timing of the attacks is suspicious.

“The whole thing just smells bad,” she said. “It does feel like there could be a connection between the DDoS and BackConnect’s timing to approach clients. On the other hand, I don’t think we received a single attack until Tucker [Preston] left BackConnect.”

DDoS attacks are rapidly growing in size, sophistication and disruptive impact, presenting a clear and present threat to online commerce and free speech alike. Since reporting about the hack of vDOS and the arrest of its proprietors nearly two weeks ago, KrebsOnSecurity.com has been under near-constant DDoS attack. One assault this past Sunday morning maxed out at more than 210 Gbps — the largest assault on this site to date.

Addressing the root causes that contribute to these attacks is a complex challenge that requires cooperation, courage and ingenuity from a broad array of constituencies — including ISPs, hosting providers, policy and hardware makers, and even end users.

In the meantime, some worry that as the disruption and chaos caused by DDoS attacks continues to worsen, network owners and providers may be increasingly tempted to take matters into their own hands and strike back at their assailants.

But this is almost never a good idea, said Rich Kulawiec, an anti-spam activist who is active on the NANOG mailing list.

“It’s tempting (and even trendy these days in portions of the security world which advocate striking back at putative attackers, never mind that attack attribution is almost entirely an unsolved problem in computing),” Kulawiec wrote. “It’s emotionally satisfying. It’s sometimes momentarily effective. But all it really does [is] open up still more attack vectors and accelerate the spiral to the bottom.”

KrebsOnSecurity would like to thank Dyn and Doug Madory for their assistance in researching the technical side of this story. For a deep dive into the BGP activity attributed to BackConnect, check out Madory’s post, BackConnect’s Suspicious Hijacks.
Top

libav: NULL pointer dereference in ff_put_pixels8_xy2_mmx (rnd_template.c)

Postby ago via agostino's blog »

Description:
Libav is an open source set of tools for audio and video processing.

A fuzzing with an mp3 file as input discovered a null pointer access in ff_put_pixels8_xy2_mmx.

The complete ASan output:

# avconv -i $FILE -f null -
avconv version 11.7, Copyright (c) 2000-2016 the Libav developers
  built on Aug 16 2016 15:34:42 with clang version 3.8.1 (tags/RELEASE_381/final)
[h263 @ 0x61a00001f280] Format detected only with low score of 25, misdetection possible!
[h263 @ 0x619000000580] warning: first frame is no keyframe
[h263 @ 0x619000000580] cbpc damaged at 2 0
[h263 @ 0x619000000580] Error at MB: 2
[h263 @ 0x619000000580] concealing 6336 DC, 6336 AC, 6336 MV errors
[h263 @ 0x61a00001f280] Estimating duration from bitrate, this may be inaccurate
Input #0, h263, from '70.crashes':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: h263, yuv420p, 1408x1152 [PAR 12:11 DAR 4:3], 25 fps, 25 tbn, 29.97 tbc
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf56.1.0
    Stream #0.0: Video: rawvideo, yuv420p, 1408x1152 [PAR 12:11 DAR 4:3], q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.1.0 rawvideo
Stream mapping:
  Stream #0:0 -> #0:0 (h263 (native) -> rawvideo (native))
Press ctrl-c to stop encoding
[h263 @ 0x61900001cc80] warning: first frame is no keyframe
[h263 @ 0x61900001cc80] cbpc damaged at 2 0
[h263 @ 0x61900001cc80] Error at MB: 2
[h263 @ 0x61900001cc80] concealing 6336 DC, 6336 AC, 6336 MV errors
[h263 @ 0x61900001cc80] warning: first frame is no keyframe
[h263 @ 0x61900001cc80] cbpc damaged at 0 0
[h263 @ 0x61900001cc80] Error at MB: 0
[h263 @ 0x61900001cc80] concealing 99 DC, 99 AC, 99 MV errors
Input stream #0:0 frame changed from size:1408x1152 fmt:yuv420p to size:176x144 fmt:yuv420p
[h263 @ 0x61900001cc80] warning: first frame is no keyframe
ASAN:DEADLYSIGNAL
=================================================================
==28973==ERROR: AddressSanitizer: SEGV on unknown address 0x7f22da99ac95 (pc 0x7f22e80d8892 bp 0x7ffcd7c28e90 sp 0x7ffcd7c28e20 T0)
    #0 0x7f22e80d8891 in ff_put_pixels8_xy2_mmx /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/x86/rnd_template.c:37:5
    #1 0x7f22e7217de0 in hpel_motion /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:224:5
    #2 0x7f22e7217de0 in apply_8x8 /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:798
    #3 0x7f22e7217de0 in mpv_motion_internal /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:877
    #4 0x7f22e7217de0 in ff_mpv_motion /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:981
    #5 0x7f22e714459b in mpv_decode_mb_internal /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo.c:2223:21
    #6 0x7f22e714459b in ff_mpv_decode_mb /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo.c:2358
    #7 0x7f22e6056c95 in decode_slice /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/h263dec.c:273:13
    #8 0x7f22e60522cd in ff_h263_decode_frame /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/h263dec.c:575:11
    #9 0x7f22e79dd906 in avcodec_decode_video2 /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/utils.c:1600:19
    #10 0x5647eb in decode_video /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:1259:11
    #11 0x5647eb in process_input_packet /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:1398
    #12 0x550e63 in process_input /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2440:11
    #13 0x550e63 in transcode /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2488
    #14 0x550e63 in main /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2647
    #15 0x7f22e3d7261f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #16 0x41d098 in _init (/usr/bin/avconv+0x41d098)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/x86/rnd_template.c:37:5 in ff_put_pixels8_xy2_mmx
==28973==ABORTING
Affected version:
11.7

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-7477

Timeline:
2016-08-15: bug discovered
2016-08-16: bug reported to upstream
2016-09-20: blog post about the issue
2016-09-21: CVE assigned

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libav: NULL pointer dereference in ff_put_pixels8_xy2_mmx (rnd_template.c)

Top

Cool new FreeBSD 11/12 kernel developer trick

Postby Warner Losh via Warner's Random Hacking Blog »

One of the cool new features in FreeBSD 11 is that we can use the system compiler as a cross compiler, eliminating the need to rebuild clang. While this allows buildworld to go much faster, there's another benefit that might not be immediately obvious.

For kernel development, this almost means we can forget about the usually required 'make kernel-toolchain' even when we're cross building. The system linker can't (yet) handle it, so the kernel fails to link if you've not done it. The good news is that you don't need to build gcc or clang for the kernel toolchain target, so you can build it quickly (in under a minute on my fast build machine, under 5 on my laptop VM). The trick is one command:
make kernel-toolchain TARGET=arm WITHOUT_{GCC,CLANG}{,_BOOTSTRAP}=t
If you are developing for amv6/v7, change TARGET=arm to TARGET_ARCH=armv6. I've not tried others, but suspect they will work as well as clang supports the target in question. This allows me to start building test kernels w/o the usual delay of building a kernel toolchain, especially on my laptop VM where  I'm chronically short on disk and always deleting the old obj tree.

This works on both 11.0 and 12.0-current. It likely will fail on 10.x since the system compiler as the cross compiler work hasn't been MFC'd there yet.
Top

This week in vc4 (2016-09-19): firmware KMS, apitrace testing

Postby Eric Anholt via anholt's lj »

While stuck on an airplane, I put together a repository for apitraces with confirmed good images for driver output.  Combined with the piglit patches I pushed, I now have regression testing of actual apps on vc4 (particularly relevant given that I'm working on optimizing one of those apps!)

The flight was to visit the Raspberry Pi Foundation, with the goal of getting something usable for their distro to switch to the open 3D stack.  There's still a giant pile of KMS work to do (HDMI audio, DSI power management, SDTV support, etc.), and waiting for all of that to be regression-free will be a long time.  The question is: what could we do that would get us 3D, even if KMS isn't ready?

So, I put together a quick branch to expose the firmware's display stack as the KMS display pipeline. It's a filthy hack, and loses us a lot of the important new features that the open stack was going to bring (changing video modes in X, vblank timestamping, power management), but it gets us much closer to the featureset of the previous stack.  Hopefully they'll be switching to it as the default in new installs soon.

In debugging while I was here, Simon found that on his HDMI display the color ramps didn't quite match between closed and open drivers.  After a bit of worrying about gamma ramp behavior, I figured out that it was actually that the monitor was using a CEA mode that requires limited range RGB input.  A patch is now on the list.
Top

Quick hack: creating a pcDuino3 bootable image from FreeBSD 11.0's BANANA PI image.

Postby Warner Losh via Warner's Random Hacking Blog »

Here's a tip about FreeBSD pre-configured armv6 images. For a given SoC, they are all (almost) the same. There's two difference for the Allwinner case (at least for the MP boards): u-boot and the hostname. Recently, I created a u-boot port for pcDuino3 as a slave port. Since I didn't care about the hostname, I thought I'd swap out the u-boot on the BANANA PI image. I snagged it from FreeBSD's download page and installed the u-boot-pcduino3 port. Allwinnner stores u-boot and a small initialization program in the first part of the SD after the MBR partition table. Other SoCs have different boot processes. Currently, you have to check the readme for each one. In the future, there will be a way to insert u-boot into any image.

So, to put the image on the SD card that showed up on my system as /dev/da2:
xz -d < FreeBSD-11.0-RC3-arm-armv6-BANANAPI.img.xz | dd of=/dev/da2 bs=1m
dd if=/usr/local/share/u-boot/u-boot-pcduino/u-boot-sunxi-with-spl.bin of=/dev/da2 bs=1k seek=8 conv=notrunc,sync
This puts the u-boot image (a SPL header which sets up the system to run u-boot coupled with u-boot) onto the disk. You can also uncompress the image you download and insert it there before pushing it out to the SD card. Since I also have a Banana PI I wanted to create an SD card for, I just changed it after it was on the image.

Unfortunately, every board needs a slightly different u-boot image. I have a number of changes I'm testing to help unify the u-boot ports. One of them adds metadata to each u-boot port that a generic imaging tool can use to make things better in the future.
Top

Chain booting u-boot with u-boot

Postby Warner Losh via Warner's Random Hacking Blog »

Recently, I needed to test u-boot before I flashed a new u-boot image into NAND. In the past, when I've googled it, I find a lot of screeds about how u-boot can't chain boot u-boot in the general case. Recently, I found a page for blackfin Linux that talks about doing just this. So, I got to thinking about trying again. I have a AT91SAM9G20. Atmel's boot process is split in two. at91bootstrap sets up the board enough to run u-boot. u-boot on Atmel boards can actually chain-boot.

So, how do I find out how to do it? I built u-boot for my board. 'objdump -f u-boot' after I built it showed:
u-boot:     file format elf32-littlearm
architecture: armv5te, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x21f00000
Generally, u-boot is loaded at the same address it executes at. So, I confirmed with objdump -x, the full output is too long to quote here, but this is relevant:
 Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0002f5e4  21f00000  21f00000  00010000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
which confirms the address. So, I booted up the old u-boot I wanted to replace and loaded u-boot.bin at 0x21f00000 and jumped to it:
RomBOOT
Start AT91Bootstrap...

U-Boot 1.3.4 (Jul 24 2009 - 17:50:12)

DRAM: 64 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Hit any key to stop autoboot: 0
U-Boot> tftp 0x21f00000 u-boot.bin
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 10.0.0.5; our IP address is 10.0.0.4
Filename 'u-boot.bin'.
Load address: 0x21f00000
Loading: ####################
done
Bytes transferred = 288984 (468d8 hex)
U-Boot> go 0x21f00000
## Starting application at 0x21F00000 ...

U-Boot 2016.05-00018-g2f0dd66 (Sep 18 2016 - 21:38:36 -0600)

CPU: AT91SAM9G20
Crystal frequency: 18.432 MHz
CPU clock : 396.288 MHz
Master clock : 132.096 MHz
DRAM: 64 MiB
WARNING: Caches not enabled
NAND: 256 MiB
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: macb0
Error: macb0 address not set.

Hit any key to stop autoboot: 0
U-Boot>
And we're in...
Top

Adapting regular iterators to asynchronous iterators in python

Postby zmedico via Zac Medico »

For I/O bound tasks, python coroutines make a nice replacement for threads. Unfortunately, there’s no asynchronous API for reading files, as discussed in the Best way to read/write files with AsyncIO thread of the python-tulip mailing list.

Meanwhile, it is essential that a long-running coroutine contain some asynchronous calls, since otherwise it will run all the way to completion before any other event loop tasks are allowed to run. For a long-running coroutine that needs to call a conventional iterator (rather than an asynchronous iterator), I’ve found this converter class to be useful:

class AsyncIteratorExecutor:
    """
    Converts a regular iterator into an asynchronous
    iterator, by executing the iterator in a thread.
    """
    def __init__(self, iterator, loop=None, executor=None):
        self.__iterator = iterator
        self.__loop = loop or asyncio.get_event_loop()
        self.__executor = executor

    def __aiter__(self):
        return self

    async def __anext__(self):
        value = await self.__loop.run_in_executor(
            self.__executor, next, self.__iterator, self)
        if value is self:
            raise StopAsyncIteration
        return value
For example, it can be used to asynchronously read lines of a text file as follows:

async def cat_file_async(filename):
    with open(filename, 'rt') as f:
        async for line in AsyncIteratorExecutor(f):
            print(line.rstrip())

if __name__ == '__main__':
    loop = asyncio.get_event_loop()
    try:
        loop.run_until_complete(
            cat_file_async('/path/of/file.txt'))
    finally:
        loop.close()
Top

25 Jahre Linux

Postby bed via Zockertown: Nerten News »

Exakt heute vor 25 Jahren war der legendäre usenet Post von Linux Torvalds, mit der Aufforderung die 0.01 Version zu testen
und vor genau 50 Jahren wurde RAUMPATROUILLE Orion im ARD ausgestrahlt
Die ARD verpennt es, aber die Linux User denken hoffentlich dran!
Alles Gute Tux!

http://www.heise.de/newsticker/meldung/25-Jahre-Linux-Happy-Birthday-3325266.html
Top

XC1506 - Webcam

Postby bed via Zockertown: Nerten News »

Notiz an mich selbst. Mein Notebook hat nach dem Kaltstart die Webcam deaktiviert, da kann ich auch in den Logs und mit lsusb nichts finden Die Webcam wird über die Hotkeys "Fn" + "F10" aktiviert.
Top

FreeBSD 11.0-RC3 Available

Postby Webmaster Team via FreeBSD News Flash »

The third RC build for the FreeBSD 11.0 release cycle is now available. ISO images for the amd64, armv6, i386, aarch64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.
Top



libav: NULL pointer dereference in put_no_rnd_pixels8_xy2_mmx (rnd_template.c)

Postby ago via agostino's blog »

Description:
Libav is an open source set of tools for audio and video processing.

A fuzzing with an mp3 file as input discovered a null pointer access in put_no_rnd_pixels8_xy2_mmx.

The complete ASan output:

# avconv -i $FILE -f null -
avconv version 11.7, Copyright (c) 2000-2016 the Libav developers
  built on Aug 16 2016 15:34:42 with clang version 3.8.1 (tags/RELEASE_381/final)
[h263 @ 0x61a00001f280] Format detected only with low score of 25, misdetection possible!
[IMGUTILS @ 0x7ff589955420] Picture size 0x0 is invalid
[h263 @ 0x619000000580] header damaged
[h263 @ 0x619000000580] Syntax-based Arithmetic Coding (SAC) not supported
[h263 @ 0x619000000580] Independent Segment Decoding not supported
[h263 @ 0x619000000580] warning: first frame is no keyframe
[h263 @ 0x619000000580] cbpc damaged at 0 0
[h263 @ 0x619000000580] Error at MB: 0
[h263 @ 0x619000000580] concealing 1584 DC, 1584 AC, 1584 MV errors
[h263 @ 0x61a00001f280] Estimating duration from bitrate, this may be inaccurate
Input #0, h263, from '9.crashes':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: h263, yuv420p, 704x576 [PAR 12:11 DAR 4:3], 25 fps, 25 tbn, 18.73 tbc
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf56.1.0
    Stream #0.0: Video: rawvideo, yuv420p, 704x576 [PAR 12:11 DAR 4:3], q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.1.0 rawvideo
Stream mapping:
  Stream #0:0 -> #0:0 (h263 (native) -> rawvideo (native))
Press ctrl-c to stop encoding
[h263 @ 0x61900001ea80] warning: first frame is no keyframe
ASAN:DEADLYSIGNAL
=================================================================
==26790==ERROR: AddressSanitizer: SEGV on unknown address 0x7ff584ddb77f (pc 0x7ff5910cdeee bp 0x7ffdc464d7f0 sp 0x7ffdc464d780 T0)
    #0 0x7ff5910cdeed in put_no_rnd_pixels8_xy2_mmx /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/x86/rnd_template.c:37:5
    #1 0x7ff590209de0 in hpel_motion /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:224:5
    #2 0x7ff590209de0 in apply_8x8 /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:798
    #3 0x7ff590209de0 in mpv_motion_internal /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:877
    #4 0x7ff590209de0 in ff_mpv_motion /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo_motion.c:981
    #5 0x7ff59013659b in mpv_decode_mb_internal /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo.c:2223:21
    #6 0x7ff59013659b in ff_mpv_decode_mb /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/mpegvideo.c:2358
    #7 0x7ff58f048c95 in decode_slice /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/h263dec.c:273:13
    #8 0x7ff58f0442cd in ff_h263_decode_frame /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/h263dec.c:575:11
    #9 0x7ff5909cf906 in avcodec_decode_video2 /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/utils.c:1600:19
    #10 0x5647eb in decode_video /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:1259:11
    #11 0x5647eb in process_input_packet /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:1398
    #12 0x550e63 in process_input /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2440:11
    #13 0x550e63 in transcode /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2488
    #14 0x550e63 in main /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/avconv.c:2647
    #15 0x7ff58cd6461f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #16 0x41d098 in _init (/usr/bin/avconv+0x41d098)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/media-video/libav-11.7/work/libav-11.7/libavcodec/x86/rnd_template.c:37:5 in put_no_rnd_pixels8_xy2_mmx
==26790==ABORTING
Affected version:
11.7

Fixed version:
N/A

Commit fix:
https://git.libav.org/?p=libav.git;a=commit;h=136f55207521f0b03194ef5b55ba70f1635d6aee

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-7424

Timeline:
2016-08-15: bug discovered
2016-08-16: bug reported to upstream
2016-09-16: upstream released a patch
2016-09-17: blog post about the issue
2016-09-17: CVE Assigned

Note:
This bug was found with American Fuzzy Lop.
This bug was reported F4B3CD@STARLAB on 2016-09-12 via libav-security while it was already public since
2016-08-15 on the upstream bugtracker.

Permalink:

libav: NULL pointer dereference in put_no_rnd_pixels8_xy2_mmx (rnd_template.c)

Top

PRL accepted: Secondary electron interference from trigonal warping in clean carbon nanotubes

Postby Andreas via the dilfridge blog »

We're very happy to announce that a few days ago one of our manuscripts, "Secondary electron interference from trigonal warping in clean carbon nanotubes", was accepted for publication in Physical Review Letters

Imagine a graphene "sheet" of carbon atoms rolled into a tube - and you get a carbon nanotube. Carbon nanotubes come in many variants, which influence strongly their electronic properties. They have different diameter, but also different "chiral angle", describing how the pattern of the carbon atoms twists around the tube axis. In our work, we show how to extract information on the nanotube structure from measurements of its conductance. At low temperature, electrons travel ballistically through a nanotube and are only scattered at its ends. For the quantum-mechanical electron wavefunction, metallic nanotubes act then analogous to an optical Fabry-Perot interferometer, i.e., a cavity with two semitransparent mirrors at either end, where a wave is partially reflected. Interference patterns are obtained by tuning the wavelength of the electrons; the current through the nanotube oscillates as a function of an applied gate voltage. The twisted graphene lattice then causes a distinct slow current modulation, which, as we show, allows a direct estimation of the chiral angle. This is an important step towards solving a highly nontrivial problem, namely identifying the precise
molecular structure of a nanotube from electronic measurements alone.

"Secondary electron interference from trigonal warping in clean carbon nanotubes"
A. Dirnaichner, M. del Valle, K. J. G. Götz, F. J. Schupp, N. Paradiso, M. Grifoni, Ch. Strunk, and A. K. Hüttel
accepted for publication in Physical Review Letters; arXiv:1602.03866 (PDF, supplemental information)
Top


Ransomware Getting More Targeted, Expensive

Postby BrianKrebs via Krebs on Security »

I shared a meal not long ago with a source who works at a financial services company. The subject of ransomware came up and he told me that a server in his company had recently been infected with a particularly nasty strain that spread to several systems before the outbreak was quarantined. He said the folks in finance didn’t bat an eyelash when asked to authorize several payments of $600 to satisfy the Bitcoin ransom demanded by the intruders: After all, my source confessed, the data on one of the infected systems was worth millions — possibly tens of millions — of dollars, but for whatever reason the company didn’t have backups of it.

This anecdote has haunted me because it speaks volumes about what we can likely expect in the very near future from ransomware — malicious software that scrambles all files on an infected computer with strong encryption, and then requires payment from the victim to recover them.



What we can expect is not only more targeted and destructive attacks, but also ransom demands that vary based on the attacker’s estimation of the value of the data being held hostage and/or the ability of the victim to pay some approximation of what it might be worth.

In an alert published today, the U.S. Federal Bureau of Investigation (FBI) warned that recent ransomware variants have targeted and compromised vulnerable business servers (rather than individual users) to identify and target hosts, thereby multiplying the number of potential infected servers and devices on a network.

“Actors engaging in this targeting strategy are also charging ransoms based on the number of host (or servers) infected,” the FBI warned. “Additionally, recent victims who have been infected with these types of ransomware variants have not been provided the decryption keys for all their files after paying the ransom, and some have been extorted for even more money after payment.”

According to the FBI, this recent technique of targeting host servers and systems “could translate into victims paying more to get their decryption keys, a prolonged recovery time, and the possibility that victims will not obtain full decryption of their files.”



Today there are dozens of ransomware strains, most of which are sold on underground forums as crimeware packages — with new families emerging regularly. These kits typically include a point-and-click software interface for selecting various options that the ransom installer may employ, as well as instructions that tell the malware where to direct the victim to pay the ransom. Some kits even bundle the HTML code needed to set up the Web site that users will need to visit to pay and recover their files.

To some degree, a variance in ransom demands based on the victim’s perceived relative wealth is already at work. Lawrence Abrams, owner of the tech-help site BleepingComputer, said his analysis of multiple ransomware kits and control channels that were compromised by security professionals indicate that these kits usually include default suggested ransom amounts that vary depending on the geographic location of the victim.

“People behind these scams seem to be setting different rates for different countries,” Abrams said. “Victims in the U.S. generally pay more than people in, say, Spain. There was one [kit] we looked at recently that showed while victims in the U.S. were charged $200 in Bitcoin, victims in Italy were asked for just $20 worth of Bitcoin by default.”

In early 2016, a new ransomware variant dubbed “Samsam” (PDF) was observed targeting businesses running outdated versions of Red Hat‘s JBoss enterprise products. When companies were hacked and infected with Samsam, Abrams said, they received custom ransom notes with varying ransom demands.

“When these companies were hacked, they each got custom notes with very different ransom demands that were much higher than the usual amount,” Abrams said. “These were very targeted.”

Which brings up the other coming shift with ransomware: More targeted ransom attacks. For the time being, most ransomware incursions are instead the result of opportunistic malware infections. The first common distribution method is spamming the ransomware installer out to millions of email addresses, disguising it as a legitimate file such as an invoice.

More well-heeled attackers may instead or also choose to spread ransomware using “exploit kits,” a separate crimeware-as-a-service product that is stitched into hacked or malicious Web sites and lying in wait for someone to visit with a browser that is not up to date with the latest security patches (either for the browser itself or for a myriad of browser plugins like Adobe Flash or Adobe Reader).

But Abrams said that’s bound to change, and that the more targeted attacks are likely to come from individual hackers who can’t afford to spend thousands of dollars a month renting exploit kits.

“If you throw your malware into a good exploit kit, you can achieve a fairly wide distribution of it in a short amount of time,” Abrams said. “The only problem is the good kits are very expensive and can cost upwards of $4,000 per month. Right now, most of these guys are just throwing the ransomware up in the air and wherever it lands is who they’re targeting. But that’s going to change, and these guys are going to start more aggressively targeting really data intensive organizations like medical practices and law and architectural firms.”

Earlier this year, experts began noticing that ransomware purveyors appeared to be targeting hospitals — organizations that are extremely data-intensive and heavily reliant on instant access to patient records. Indeed, the above-mentioned SamSAM ransomware family is thought to be targeting healthcare firms.

According to a new report by Intel Security, the healthcare sector is experiencing over 20 data loss incidents per day related to ransomware attacks. The company said it identified almost $100,000 in payments from hospital ransomware victims to specific bitcoin accounts so far in 2016.

RUSSIAN ROULETTE

An equally disturbing trend in ransomware is the incidence of new strains which include the ability to randomly delete an encrypted file from the victim’s machine at some predefined interval –and to continue doing so unless and until the ransom demand is paid or there are no more files to destroy.

Abrams said the a ransomware variant known as “Jigsaw” debuted this capability in April 2016. Jigsaw also penalized victims who tried to reboot their computer in an effort to rid the machine of the infection, by randomly deleting 1,000 encrypted files for each reboot.

“Basically, what it would do is show a two hour countdown clock, and when that clock got to zero it would delete a random encrypted file,” Abrams said. “And then every hour after that it would double the number of files it deleted unless you paid.”

Part of the ransom note left behind by Jigsaw. Image: Bleepingcomputer.com
Abrams said this same Russian Roulette feature recently has shown up in other ransomware strains, including one called “Stampado” and another dubbed “Philadelphia.”

“Philadelphia has a similar feature where [one] can specify how many files it deletes and how often,” he said.

Most ransomware variants have used some version of the countdown clock, with victims most often being told they have 72 hours to pay the ransom or else kiss their files goodbye forever. In practice, however, the people behind these schemes are usually happy to extend that deadline, but the ransom demands almost invariably increase significantly at that point.

The introduction of a destructive element tied to a countdown clock is especially worrisome given how difficult it can be for the unlearned to obtain the virtual Bitcoin currency needed to pay the ransom, Abrams said.

“I had an architectural firm reach out to me, and they’d decided to pay the ransom,” he said. “So I helped my contact there figure out how to create an account at Coinbase.com and get funds into there, but the whole process took almost a week.”

Hoping to get access to his files more immediately, Abrams’ contact at the architectural firm inquired about more speedy payment options. Abrams told him about localbitcoins.com, which helps people meet in person to exchange bitcoins for cash. In the end, however, the contact wasn’t comfortable with this option.

“It’s not hard to see why,” he said. “Some of the exchangers on there have crazy demands, like ‘Meet me at the local Starbucks, and absolutely no phones!’ It really sort of feels like a drug deal.”

The ransom demand left by Stampado. Image: Bleepingcomputer.com

HOW TO PREVENT ATTACKS & WHAT TO DO IF YOU’RE A VICTIM

In its alert published today, the FBI urged victims of ransomware incidents to report the crimes to federal law enforcement to help the government “gain a more comprehensive view of the current threat and its impact on U.S. victims.”

Specifically, the FBI is asking victims to report the date of infection; the ransomware variant; how the infection occurred; the requested ransom amount; the actors Bitcoin wallet address; the ransom amount paid (if any); the overall losses associated with the ransomware infection; and a victim impact statement.

Previous media reports have quoted an FBI agent saying that the agency condones paying such ransom demands. But today’s plea from the feds to ransomware victims is unequivocal on this point:

“The FBI does not support paying a ransom to the adversary,” the agency advised. “Paying a ransom does not guarantee the victim will regain access to their data; in fact, some individuals or organizations are never provided with decryption keys after paying a ransom.”

What can businesses do to lessen the chances of becoming the next ransomware victim? The FBI has the following tips:

  • Regularly back up data and verify the integrity of those backups. Backups are critical in ransomware incidents; if you are infected, backups may be the best way to recover your critical data.
  • Secure your backups. Ensure backups are not connected to the computers and networks they are backing up. Examples might include securing backups in the cloud or physically storing them offline. It should be noted, some instances of ransomware have the capability to lock cloud-based backups when systems continuously back up in real-time, also known as persistent synchronization.
  • Scrutinize links contained in e-mails and do not open attachments included in unsolicited e-mails.
  • Only download software – especially free software – from sites you know and trust. When possible, verify the integrity of the software through a digital signature prior to execution.
  • Ensure application patches for the operating system, software, and firmware are up to date, including Adobe Flash, Java, Web browsers, etc.
  • Ensure anti-virus and anti-malware solutions are set to automatically update and regular scans are conducted.
  • Disable macro scripts from files transmitted via e-mail. Consider using Office Viewer software to open Microsoft Office files transmitted via e-mail instead of full Office Suite applications.
  • Implement software restrictions or other controls to prevent the execution of programs in common ransomware locations, such as temporary folders supporting popular Internet browsers, or compression/decompression programs, including those located in the AppData/LocalAppData folder.
Additional considerations for businesses include the following:

  • Focus on awareness and training. Because end users are often targeted, employees should be made aware of the threat of ransomware, how it is delivered, and trained on information security principles and techniques.
  • Patch all endpoint device operating systems, software, and firmware as vulnerabilities are discovered. This precaution can be made easier through a centralized patch management system.
  • Manage the use of privileged accounts by implementing the principle of least privilege. No users should be assigned administrative access unless absolutely needed. Those with a need for administrator accounts should only use them when necessary; they should operate with standard user accounts at all other times.
  • Configure access controls with least privilege in mind. If a user only needs to read specific files, he or she should not have write access to those files, directories, or shares.
  • Use virtualized environments to execute operating system environments or specific programs.
  • Categorize data based on organizational value, and implement physical/logical separation of networks and data for different organizational units. For example, sensitive research or business data should not reside on the same server and/or network segment as an organization’s e-mail environment.
  • Require user interaction for end user applications communicating with Web sites uncategorized by the network proxy or firewall. Examples include requiring users to type in information or enter a password when the system communicates with an uncategorized Web site.
  • Implement application whitelisting. Only allow systems to execute programs known and permitted by security policy.
Top

graphicsmagick: memory allocation failure in MagickMalloc (memory.c)

Postby ago via agostino's blog »

Description:
Graphicsmagick is an Image Processing System.

After the first round of fuzzing where I discovered some slowness issues that make the fuzz hard, the second round revealed a memory allocation failure.

The complete ASan output:

# gm identify $FILE
==20592==ERROR: AddressSanitizer failed to allocate 0x7fff03000 (34358702080) bytes of LargeMmapAllocator (error code: 12)
==20592==Process memory map follows:
        0x000000400000-0x000000522000   /usr/bin/gm
        0x000000722000-0x000000723000   /usr/bin/gm
        0x000000723000-0x000000726000   /usr/bin/gm
        0x000000726000-0x000001399000
        0x00007fff7000-0x00008fff7000
        0x00008fff7000-0x02008fff7000
        0x02008fff7000-0x10007fff8000
        0x600000000000-0x602000000000
        0x602000000000-0x602000010000
        0x602000010000-0x603000000000
        0x603000000000-0x603000010000
        0x603000010000-0x604000000000
        0x604000000000-0x604000010000
        0x604000010000-0x606000000000
        0x606000000000-0x606000010000
        0x606000010000-0x607000000000
        0x607000000000-0x607000010000
        0x607000010000-0x608000000000
        0x608000000000-0x608000010000
        0x608000010000-0x60a000000000
        0x60a000000000-0x60a000010000
        0x60a000010000-0x60b000000000
        0x60b000000000-0x60b000010000
        0x60b000010000-0x60c000000000
        0x60c000000000-0x60c000010000
        0x60c000010000-0x60d000000000
        0x60d000000000-0x60d000010000
        0x60d000010000-0x60f000000000
        0x60f000000000-0x60f000010000
        0x60f000010000-0x610000000000
        0x610000000000-0x610000010000
        0x610000010000-0x611000000000
        0x611000000000-0x611000010000
        0x611000010000-0x612000000000
        0x612000000000-0x612000010000
        0x612000010000-0x614000000000
        0x614000000000-0x614000020000
        0x614000020000-0x616000000000
        0x616000000000-0x616000020000
        0x616000020000-0x618000000000
        0x618000000000-0x618000020000
        0x618000020000-0x619000000000
        0x619000000000-0x619000020000
        0x619000020000-0x61a000000000
        0x61a000000000-0x61a000020000
        0x61a000020000-0x61b000000000
        0x61b000000000-0x61b000020000
        0x61b000020000-0x61d000000000
        0x61d000000000-0x61d000020000
        0x61d000020000-0x61e000000000
        0x61e000000000-0x61e000020000
        0x61e000020000-0x621000000000
        0x621000000000-0x621000020000
        0x621000020000-0x623000000000
        0x623000000000-0x623000020000
        0x623000020000-0x624000000000
        0x624000000000-0x624000020000
        0x624000020000-0x625000000000
        0x625000000000-0x625000020000
        0x625000020000-0x640000000000
        0x640000000000-0x640000003000
        0x7f889986d000-0x7f889988b000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/sgi.so
        0x7f889988b000-0x7f8899a8a000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/sgi.so
        0x7f8899a8a000-0x7f8899a8b000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/sgi.so
        0x7f8899a8b000-0x7f8899a8c000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/sgi.so
        0x7f8899a8c000-0x7f8899a8e000
        0x7f8899a8e000-0x7f88a0100000   /usr/lib64/locale/locale-archive
        0x7f88a0100000-0x7f88a0200000
        0x7f88a0300000-0x7f88a0400000
        0x7f88a049b000-0x7f88a27ed000
        0x7f88a27ed000-0x7f88a27f6000   /usr/lib64/libltdl.so.7.3.1
        0x7f88a27f6000-0x7f88a29f5000   /usr/lib64/libltdl.so.7.3.1
        0x7f88a29f5000-0x7f88a29f6000   /usr/lib64/libltdl.so.7.3.1
        0x7f88a29f6000-0x7f88a29f7000   /usr/lib64/libltdl.so.7.3.1
        0x7f88a29f7000-0x7f88a2a0c000   /lib64/libz.so.1.2.8
        0x7f88a2a0c000-0x7f88a2c0b000   /lib64/libz.so.1.2.8
        0x7f88a2c0b000-0x7f88a2c0c000   /lib64/libz.so.1.2.8
        0x7f88a2c0c000-0x7f88a2c0d000   /lib64/libz.so.1.2.8
        0x7f88a2c0d000-0x7f88a2c1c000   /lib64/libbz2.so.1.0.6
        0x7f88a2c1c000-0x7f88a2e1b000   /lib64/libbz2.so.1.0.6
        0x7f88a2e1b000-0x7f88a2e1c000   /lib64/libbz2.so.1.0.6
        0x7f88a2e1c000-0x7f88a2e1d000   /lib64/libbz2.so.1.0.6
        0x7f88a2e1d000-0x7f88a2ec4000   /usr/lib64/libfreetype.so.6.12.3
        0x7f88a2ec4000-0x7f88a30c4000   /usr/lib64/libfreetype.so.6.12.3
        0x7f88a30c4000-0x7f88a30ca000   /usr/lib64/libfreetype.so.6.12.3
        0x7f88a30ca000-0x7f88a30cb000   /usr/lib64/libfreetype.so.6.12.3
        0x7f88a30cb000-0x7f88a311f000   /usr/lib64/liblcms2.so.2.0.6
        0x7f88a311f000-0x7f88a331e000   /usr/lib64/liblcms2.so.2.0.6
        0x7f88a331e000-0x7f88a331f000   /usr/lib64/liblcms2.so.2.0.6
        0x7f88a331f000-0x7f88a3324000   /usr/lib64/liblcms2.so.2.0.6
        0x7f88a3324000-0x7f88a34b7000   /lib64/libc-2.22.so
        0x7f88a34b7000-0x7f88a36b7000   /lib64/libc-2.22.so
        0x7f88a36b7000-0x7f88a36bb000   /lib64/libc-2.22.so
        0x7f88a36bb000-0x7f88a36bd000   /lib64/libc-2.22.so
        0x7f88a36bd000-0x7f88a36c1000
        0x7f88a36c1000-0x7f88a36d7000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f88a36d7000-0x7f88a38d6000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f88a38d6000-0x7f88a38d7000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f88a38d7000-0x7f88a38d8000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7f88a38d8000-0x7f88a38de000   /lib64/librt-2.22.so
        0x7f88a38de000-0x7f88a3ade000   /lib64/librt-2.22.so
        0x7f88a3ade000-0x7f88a3adf000   /lib64/librt-2.22.so
        0x7f88a3adf000-0x7f88a3ae0000   /lib64/librt-2.22.so
        0x7f88a3ae0000-0x7f88a3af7000   /lib64/libpthread-2.22.so
        0x7f88a3af7000-0x7f88a3cf6000   /lib64/libpthread-2.22.so
        0x7f88a3cf6000-0x7f88a3cf7000   /lib64/libpthread-2.22.so
        0x7f88a3cf7000-0x7f88a3cf8000   /lib64/libpthread-2.22.so
        0x7f88a3cf8000-0x7f88a3cfc000
        0x7f88a3cfc000-0x7f88a3df9000   /lib64/libm-2.22.so
        0x7f88a3df9000-0x7f88a3ff8000   /lib64/libm-2.22.so
        0x7f88a3ff8000-0x7f88a3ff9000   /lib64/libm-2.22.so
        0x7f88a3ff9000-0x7f88a3ffa000   /lib64/libm-2.22.so
        0x7f88a3ffa000-0x7f88a3ffc000   /lib64/libdl-2.22.so
        0x7f88a3ffc000-0x7f88a41fc000   /lib64/libdl-2.22.so
        0x7f88a41fc000-0x7f88a41fd000   /lib64/libdl-2.22.so
        0x7f88a41fd000-0x7f88a41fe000   /lib64/libdl-2.22.so
        0x7f88a41fe000-0x7f88a4a0d000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7f88a4a0d000-0x7f88a4c0d000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7f88a4c0d000-0x7f88a4c3e000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7f88a4c3e000-0x7f88a4cc4000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7f88a4cc4000-0x7f88a4d3f000
        0x7f88a4d3f000-0x7f88a4d61000   /lib64/ld-2.22.so
        0x7f88a4eab000-0x7f88a4ec0000
        0x7f88a4ec0000-0x7f88a4ec7000   /usr/lib64/gconv/gconv-modules.cache
        0x7f88a4ec7000-0x7f88a4eea000   /usr/share/locale/it/LC_MESSAGES/libc.mo
        0x7f88a4eea000-0x7f88a4f54000
        0x7f88a4f54000-0x7f88a4f60000
        0x7f88a4f60000-0x7f88a4f61000   /lib64/ld-2.22.so
        0x7f88a4f61000-0x7f88a4f62000   /lib64/ld-2.22.so
        0x7f88a4f62000-0x7f88a4f63000
        0x7ffe83ea9000-0x7ffe83eca000   [stack]
        0x7ffe83f49000-0x7ffe83f4b000   [vvar]
        0x7ffe83f4b000-0x7ffe83f4d000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==20592==End of process memory map.
==20592==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x4c9aed in AsanCheckFailed /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67
    #1 0x4d0623 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159
    #2 0x4d0811 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char const*, char const*, int, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183
    #3 0x4d984a in __sanitizer::MmapOrDie(unsigned long, char const*, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:122
    #4 0x421bdf in __sanitizer::LargeMmapAllocator::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1033
    #5 0x421bdf in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1302
    #6 0x421bdf in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:368
    #7 0x421bdf in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:718
    #8 0x4c01b1 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:53
    #9 0x7f88a479e12d in MagickMalloc /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/memory.c:156:10
    #10 0x7f88a479e12d in MagickMallocArray /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/memory.c:347
    #11 0x7f8899872d7a in ReadSGIImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/coders/sgi.c:498:19
    #12 0x7f88a4558b13 in ReadImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/constitute.c:1607:13
    #13 0x7f88a4556a94 in PingImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/constitute.c:1370:9
    #14 0x7f88a446bb25 in IdentifyImageCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:8375:17
    #15 0x7f88a447197c in MagickCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:8865:17
    #16 0x7f88a44e96fe in GMCommandSingle /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:17379:10
    #17 0x7f88a44e7926 in GMCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:17432:16
    #18 0x7f88a334461f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #19 0x418c88 in _init (/usr/bin/gm+0x418c88)
Affected version:
1.3.25

Fixed version:
1.3.26 (not yet released)

Commit fix:
http://hg.code.sf.net/p/graphicsmagick/code/rev/c53725cb5449

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-09-09: bug discovered
2016-09-09: bug reported privately to upstream
2016-09-10: no upstream response
2016-09-15: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

graphicsmagick: memory allocation failure in MagickMalloc (memory.c)

Top

graphicsmagick: memory allocation failure in ReadPCXImage (pcx.c)

Postby ago via agostino's blog »

Description:
Graphicsmagick is an Image Processing System.

After the first round of fuzzing where I discovered some slowness issues that make the fuzz hard, the second round revealed a memory allocation failure.

The complete ASan output:

# gm identify $FILE
==10139==ERROR: AddressSanitizer failed to allocate 0x4cd6a6000 (20626169856) bytes of LargeMmapAllocator (error code: 12)                                                                                                                                                     
==10139==Process memory map follows:                                                                                                                                                                                                                                           
        0x000000400000-0x00000051f000   /usr/bin/gm                                                                                                                                                                                                                            
        0x00000071e000-0x00000071f000   /usr/bin/gm                                                                                                                                                                                                                            
        0x00000071f000-0x000000722000   /usr/bin/gm                                                                                                                                                                                                                            
        0x000000722000-0x000001394000                                                                                                                                                                                                                                          
        0x00007fff7000-0x00008fff7000                                                                                                                                                                                                                                          
        0x00008fff7000-0x02008fff7000                                                                                                                                                                                                                                          
        0x02008fff7000-0x10007fff8000                                                                                                                                                                                                                                          
        0x600000000000-0x602000000000                                                                                                                                                                                                                                          
        0x602000000000-0x602000010000                                                                                                                                                                                                                                          
        0x602000010000-0x603000000000                                                                                                                                                                                                                                          
        0x603000000000-0x603000010000                                                                                                                                                                                                                                          
        0x603000010000-0x604000000000                                                                                                                                                                                                                                          
        0x604000000000-0x604000010000                                                                                                                                                                                                                                          
        0x604000010000-0x606000000000                                                                                                                                                                                                                                          
        0x606000000000-0x606000010000                                                                                                                                                                                                                                          
        0x606000010000-0x607000000000                                                                                                                                                                                                                                          
        0x607000000000-0x607000010000                                                                                                                                                                                                                                          
        0x607000010000-0x608000000000                                                                                                                                                                                                                                          
        0x608000000000-0x608000010000                                                                                                                                                                                                                                          
        0x608000010000-0x60a000000000                                                                                                                                                                                                                                          
        0x60a000000000-0x60a000010000                                                                                                                                                                                                                                          
        0x60a000010000-0x60b000000000                                                                                                                                                                                                                                          
        0x60b000000000-0x60b000010000                                                                                                                                                                                                                                          
        0x60b000010000-0x60c000000000                                                                                                                                                                                                                                          
        0x60c000000000-0x60c000010000                                                                                                                                                                                                                                          
        0x60c000010000-0x60f000000000                                                                                                                                                                                                                                          
        0x60f000000000-0x60f000010000                                                                                                                                                                                                                                          
        0x60f000010000-0x610000000000                                                                                                                                                                                                                                          
        0x610000000000-0x610000010000                                                                                                                                                                                                                                          
        0x610000010000-0x611000000000                                                                                                                                                                                                                                          
        0x611000000000-0x611000010000                                                                                                                                                                                                                                          
        0x611000010000-0x612000000000                                                                                                                                                                                                                                          
        0x612000000000-0x612000010000                                                                                                                                                                                                                                          
        0x612000010000-0x614000000000                                                                                                                                                                                                                                          
        0x614000000000-0x614000020000                                                                                                                                                                                                                                          
        0x614000020000-0x616000000000                                                                                                                                                                                                                                          
        0x616000000000-0x616000020000                                                                                                                                                                                                                                          
        0x616000020000-0x618000000000                                                                                                                                                                                                                                          
        0x618000000000-0x618000020000                                                                                                                                                                                                                                          
        0x618000020000-0x619000000000                                                                                                                                                                                                                                          
        0x619000000000-0x619000020000                                                                                                                                                                                                                                          
        0x619000020000-0x61a000000000
        0x61a000000000-0x61a000020000
        0x61a000020000-0x61b000000000
        0x61b000000000-0x61b000020000
        0x61b000020000-0x61d000000000
        0x61d000000000-0x61d000020000
        0x61d000020000-0x61e000000000
        0x61e000000000-0x61e000020000
        0x61e000020000-0x621000000000
        0x621000000000-0x621000020000
        0x621000020000-0x623000000000
        0x623000000000-0x623000020000
        0x623000020000-0x624000000000
        0x624000000000-0x624000020000
        0x624000020000-0x625000000000
        0x625000000000-0x625000020000
        0x625000020000-0x640000000000
        0x640000000000-0x640000003000
        0x7ff8e8877000-0x7ff8e888c000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/pcx.so
        0x7ff8e888c000-0x7ff8e8a8c000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/pcx.so
        0x7ff8e8a8c000-0x7ff8e8a8d000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/pcx.so
        0x7ff8e8a8d000-0x7ff8e8a8e000   /usr/lib64/GraphicsMagick-1.3.25/modules-Q32/coders/pcx.so
        0x7ff8e8a8e000-0x7ff8ef100000   /usr/lib64/locale/locale-archive
        0x7ff8ef100000-0x7ff8ef200000
        0x7ff8ef300000-0x7ff8ef400000
        0x7ff8ef4ab000-0x7ff8f17fd000
        0x7ff8f17fd000-0x7ff8f1806000   /usr/lib64/libltdl.so.7.3.1
        0x7ff8f1806000-0x7ff8f1a05000   /usr/lib64/libltdl.so.7.3.1
        0x7ff8f1a05000-0x7ff8f1a06000   /usr/lib64/libltdl.so.7.3.1
        0x7ff8f1a06000-0x7ff8f1a07000   /usr/lib64/libltdl.so.7.3.1
        0x7ff8f1a07000-0x7ff8f1a1c000   /lib64/libz.so.1.2.8
        0x7ff8f1a1c000-0x7ff8f1c1b000   /lib64/libz.so.1.2.8
        0x7ff8f1c1b000-0x7ff8f1c1c000   /lib64/libz.so.1.2.8
        0x7ff8f1c1c000-0x7ff8f1c1d000   /lib64/libz.so.1.2.8
        0x7ff8f1c1d000-0x7ff8f1c2c000   /lib64/libbz2.so.1.0.6
        0x7ff8f1c2c000-0x7ff8f1e2b000   /lib64/libbz2.so.1.0.6
        0x7ff8f1e2b000-0x7ff8f1e2c000   /lib64/libbz2.so.1.0.6
        0x7ff8f1e2c000-0x7ff8f1e2d000   /lib64/libbz2.so.1.0.6
        0x7ff8f1e2d000-0x7ff8f1ed4000   /usr/lib64/libfreetype.so.6.12.3
        0x7ff8f1ed4000-0x7ff8f20d4000   /usr/lib64/libfreetype.so.6.12.3
        0x7ff8f20d4000-0x7ff8f20da000   /usr/lib64/libfreetype.so.6.12.3
        0x7ff8f20da000-0x7ff8f20db000   /usr/lib64/libfreetype.so.6.12.3
        0x7ff8f20db000-0x7ff8f212f000   /usr/lib64/liblcms2.so.2.0.6
        0x7ff8f212f000-0x7ff8f232e000   /usr/lib64/liblcms2.so.2.0.6
        0x7ff8f232e000-0x7ff8f232f000   /usr/lib64/liblcms2.so.2.0.6
        0x7ff8f232f000-0x7ff8f2334000   /usr/lib64/liblcms2.so.2.0.6
        0x7ff8f2334000-0x7ff8f24c7000   /lib64/libc-2.22.so
        0x7ff8f24c7000-0x7ff8f26c7000   /lib64/libc-2.22.so
        0x7ff8f26c7000-0x7ff8f26cb000   /lib64/libc-2.22.so
        0x7ff8f26cb000-0x7ff8f26cd000   /lib64/libc-2.22.so
        0x7ff8f26cd000-0x7ff8f26d1000
        0x7ff8f26d1000-0x7ff8f26e7000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7ff8f26e7000-0x7ff8f28e6000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7ff8f28e6000-0x7ff8f28e7000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7ff8f28e7000-0x7ff8f28e8000   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1
        0x7ff8f28e8000-0x7ff8f28ee000   /lib64/librt-2.22.so
        0x7ff8f28ee000-0x7ff8f2aee000   /lib64/librt-2.22.so
        0x7ff8f2aee000-0x7ff8f2aef000   /lib64/librt-2.22.so
        0x7ff8f2aef000-0x7ff8f2af0000   /lib64/librt-2.22.so
        0x7ff8f2af0000-0x7ff8f2b07000   /lib64/libpthread-2.22.so
        0x7ff8f2b07000-0x7ff8f2d06000   /lib64/libpthread-2.22.so
        0x7ff8f2d06000-0x7ff8f2d07000   /lib64/libpthread-2.22.so
        0x7ff8f2d07000-0x7ff8f2d08000   /lib64/libpthread-2.22.so
        0x7ff8f2d08000-0x7ff8f2d0c000
        0x7ff8f2d0c000-0x7ff8f2e09000   /lib64/libm-2.22.so
        0x7ff8f2e09000-0x7ff8f3008000   /lib64/libm-2.22.so
        0x7ff8f3008000-0x7ff8f3009000   /lib64/libm-2.22.so
        0x7ff8f3009000-0x7ff8f300a000   /lib64/libm-2.22.so
        0x7ff8f300a000-0x7ff8f300c000   /lib64/libdl-2.22.so
        0x7ff8f300c000-0x7ff8f320c000   /lib64/libdl-2.22.so
        0x7ff8f320c000-0x7ff8f320d000   /lib64/libdl-2.22.so
        0x7ff8f320d000-0x7ff8f320e000   /lib64/libdl-2.22.so
        0x7ff8f320e000-0x7ff8f387c000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7ff8f387c000-0x7ff8f3a7b000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7ff8f3a7b000-0x7ff8f3aa3000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7ff8f3aa3000-0x7ff8f3afd000   /usr/lib64/libGraphicsMagick.so.3.15.1
        0x7ff8f3afd000-0x7ff8f3b01000
        0x7ff8f3b01000-0x7ff8f3b23000   /lib64/ld-2.22.so
        0x7ff8f3c79000-0x7ff8f3c8e000
        0x7ff8f3c8e000-0x7ff8f3c95000   /usr/lib64/gconv/gconv-modules.cache
        0x7ff8f3c95000-0x7ff8f3cb8000   /usr/share/locale/it/LC_MESSAGES/libc.mo
        0x7ff8f3cb8000-0x7ff8f3d16000
        0x7ff8f3d16000-0x7ff8f3d22000
        0x7ff8f3d22000-0x7ff8f3d23000   /lib64/ld-2.22.so
        0x7ff8f3d23000-0x7ff8f3d24000   /lib64/ld-2.22.so
        0x7ff8f3d24000-0x7ff8f3d25000
        0x7fffd09c8000-0x7fffd09e9000   [stack]
        0x7fffd09f0000-0x7fffd09f2000   [vvar]
        0x7fffd09f2000-0x7fffd09f4000   [vdso]
        0xffffffffff600000-0xffffffffff601000   [vsyscall]
==10139==End of process memory map.
==10139==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
    #0 0x4c973d in AsanCheckFailed /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_rtl.cc:67
    #1 0x4d0273 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:159
    #2 0x4d0461 in __sanitizer::ReportMmapFailureAndDie(unsigned long, char const*, char const*, int, bool) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183
    #3 0x4d949a in __sanitizer::MmapOrDie(unsigned long, char const*, bool) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:122
    #4 0x42182f in __sanitizer::LargeMmapAllocator::Allocate(__sanitizer::AllocatorStats*, unsigned long, unsigned long) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1033
    #5 0x42182f in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator >::Allocate(__sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap, __asan::AsanMapUnmapCallback> >*, unsigned long, unsigned long, bool, bool) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator.h:1302
    #6 0x42182f in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:368
    #7 0x42182f in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_allocator.cc:718
    #8 0x4bfe01 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:53
    #9 0x7ff8e887beba in ReadPCXImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/coders/pcx.c:467:16
    #10 0x7ff8f34a4c4e in ReadImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/constitute.c:1607:13
    #11 0x7ff8f34a4294 in PingImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/constitute.c:1370:9
    #12 0x7ff8f33f5836 in IdentifyImageCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:8375:17
    #13 0x7ff8f33f9e23 in MagickCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:8865:17
    #14 0x7ff8f344fc3e in GMCommandSingle /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:17379:10
    #15 0x7ff8f344e5d1 in GMCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:17432:16
    #16 0x7ff8f235461f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #17 0x4188d8 in _init (/usr/bin/gm+0x4188d8)
Affected version:
1.3.25

Fixed version:
1.3.26 (not yet released)

Commit fix:
http://hg.code.sf.net/p/graphicsmagick/code/rev/b9edafd479b9

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-09-09: bug discovered
2016-09-09: bug reported privately to upstream
2016-09-10: no upstream response
2016-09-15: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

graphicsmagick: memory allocation failure in ReadPCXImage (pcx.c)

Top

graphicsmagick: stack-based buffer overflow in ReadSCTImage (sct.c)

Postby ago via agostino's blog »

Description:
Graphicsmagick is an Image Processing System.

After the first round of fuzzing where I discovered some slowness issues that make the fuzz hard, the second round revealed a stack-buffer-overflow.

The complete ASan output:

# gm identify $FILE
==23362==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffaab3b8e0 at pc 0x000000453e36 bp 0x7fffaab3b570 sp 0x7fffaab3ad20
READ of size 769 at 0x7fffaab3b8e0 thread T0
    #0 0x453e35 in StrtolFixAndCheck /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2596
    #1 0x4545c1 in __interceptor_strtol /var/tmp/portage/sys-devel/llvm-3.8.1-r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:633
    #2 0x7f73e9a847df in ReadSCTImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/coders/sct.c:191:19
    #3 0x7f73f473eb13 in ReadImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/constitute.c:1607:13
    #4 0x7f73f473ca94 in PingImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/constitute.c:1370:9
    #5 0x7f73f4651b25 in IdentifyImageCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:8375:17
    #6 0x7f73f465797c in MagickCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:8865:17
    #7 0x7f73f46cf6fe in GMCommandSingle /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:17379:10
    #8 0x7f73f46cd926 in GMCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/magick/command.c:17432:16
    #9 0x7f73f352a61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #10 0x418c88 in _init (/usr/bin/gm+0x418c88)

Address 0x7fffaab3b8e0 is located in stack of thread T0 at offset 800 in frame
    #0 0x7f73e9a8399f in ReadSCTImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.25/work/GraphicsMagick-1.3.25/coders/sct.c:126

  This frame has 2 object(s):
    [32, 800) 'buffer'
    [928, 930) 'magick' 0x10007555f710: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
  0x10007555f720: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 02 f3 f3 f3
  0x10007555f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007555f740: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 00 f2
  0x10007555f750: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007555f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==23362==ABORTING
Affected version:
1.3.25

Fixed version:
1.3.26 ( not yet released)

Commit fix:
http://hg.code.sf.net/p/graphicsmagick/code/rev/0a0dfa81906d

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-09-09: bug discovered
2016-09-09: bug reported privately to upstream
2016-09-10: no upstream response
2016-09-15: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

graphicsmagick: stack-based buffer overflow in ReadSCTImage (sct.c)

Top

Adobe, Microsoft Push Critical Updates

Postby BrianKrebs via Krebs on Security »

Adobe and Microsoft on Tuesday each issued updates to fix multiple critical security vulnerabilities in their software. Adobe pushed a patch that addresses 29 security holes in its widely-used Flash Player browser plug-in. Microsoft released some 14 patch bundles to correct at least 50 flaws in Windows and associated software, including a zero-day bug in Internet Explorer.

Half of the updates Microsoft released Tuesday earned the company’s most dire “critical” rating, meaning they could be exploited by malware or miscreants to install malicious software with no help from the user, save for maybe just visiting a hacked or booby-trapped Web site. Security firms Qualys and Shavlik have more granular writeups on the Microsoft patches.

Adobe’s advisory for this Flash Update is here. It brings Flash to v. 23.0.0.162 for Windows and Mac users. If you have Flash installed, you should update, hobble or remove Flash as soon as possible.

The smartest option is probably to ditch the program once and for all and significantly increase the security of your system in the process. I’ve got more on that approach (as well as slightly less radical solutions ) in A Month Without Adobe Flash Player.

If you choose to update, please do it today. The most recent versions of Flash should be available from this Flash distribution page or the Flash home page. Windows users who browse the Web with anything other than Internet Explorer may need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

Chrome and IE should auto-install the latest Flash version on browser restart (I had to manually check for updates in Chrome an restart the browser to get the latest Flash version).

As always, if you run into any issues installing any of these updates, please feel free to leave a comment about your experience below.
Top

This week in vc4 2016-09-13: glmark2 performance work

Postby Eric Anholt via anholt's lj »

Last week I spent working on the glmark2 performance issues.  I now have a NIR patch out for the pathological conditionals test (it's now faster than on the old driver), and a branch for job shuffling (+17% and +27% on the two desktop tests).

Here's the basic idea of job shuffling:

We're a tiled renderer, and tiled renderers get their wins from having a Clear at the start of the frame (indicating we don't need to load any previous contents into the tile buffer).  When your frame is done, we flush each tile out to memory.  If you do your clear, start rendering some primitives, and then switch to some other FBO (because you're rendering to a texture that you're planning on texturing from in your next draw to the main FBO), we have to flush out all of those tiles, start rendering to the new FBO, and flush its rendering, and then when you come back to the main FBO and we have to reload your old cleared-and-a-few-draws tiles.

Job shuffling deals with this by separating the single GL command stream into separate jobs per FBO.  When you switch to your temporary FBO, we don't flush the old job, we just set it aside.  To make this work we have to add tracking for which buffers have jobs writing into them (so that if you try to read those from another job, we can go flush the job that wrote it), and which buffers have jobs reading from them (so that if you try to write to them, they can get flushed so that they don't get incorrectly updated contents).

This felt like it should have been harder than it was, and there's a spot where I'm using a really bad data structure I had laying around, but that data structure has been bad news since the driver was imported and it hasn't been high in any profiles yet.  The other tests don't seem to have any problem with the possible increased CPU overhead.

The shuffling branch also unearthed a few bugs related to clearing and blitting in the multisample tests.  Some of the piglit cases involved are fixed, but some will be reporting new piglit "regressions" because the tests are now closer to working correctly (sigh, reftests).

I also started writing documentation for updating the system's X and Mesa stack on Raspbian for one of the Foundation's developers.  It's not polished, and if I was rewriting it I would use modular's build.sh instead of some of what I did there.  But it's there for reference.
Top

Moving from shelves to racks

Postby Dan Langille via Dan Langille's Other Diary »

The time has come for me to move from shelving to racks. My first thought was to list the various racks over the years. Look below for old photos and links to the posts I lifted them from. Why a rack? In the past, I have always built my own servers, computers, from parts. I [...]
Top

Secret Service Warns of ‘Periscope’ Skimmers

Postby BrianKrebs via Krebs on Security »

The U.S. Secret Service is warning banks and ATM owners about a new technological advance in cash machine skimming known as “periscope skimming,” which involves a specialized skimming probe that connects directly to the ATM’s internal circuit board to steal card data.

At left, the skimming control device. Pictured right is the skimming control device with wires protruding from the periscope. These were recovered from a cash machine in Connecticut.
According to a non-public alert released to bank industry sources by a financial crimes task force in Connecticut, this is thought to be the first time periscope skimming devices have been detected in the United States. The task force warned that the devices may have the capability to remain powered within the ATM for up to 14 days and can store up to 32,000 card numbers before exhausting the skimmer’s battery strength and data storage capacity.

The alert documents the first known case of periscope skimming in the United States, discovered Aug. 19, 2016 at an ATM in Greenwich, Conn. A second periscope skimmer was reportedly found hidden inside a cash machine in Pennsylvania on Sept. 3.

The periscope device.
The task force alert notes that in both cases the crooks were able to gain direct access to the insides of the ATMs (referred to as “top-hat” entry) with a key. The suspects then installed two devices connected together by wiring. The first device — the periscope skimming probe — is installed through a pre-existing hole on the frame of the motorized card reader.

The probe is set in place to connect to the circuit board and directly onto the pad that transfers cardholder data stored on the magnetic stripe on the backs of customer payment cards. The probe is then held in place with fast-drying superglue to the card reader frame.

According to the Secret Service, the only visible part of this skimming device once the top-hat is opened will be the wire extending from the periscope probe that leads to the second part of this skimmer — called a “skimming control device.” This second device contains the battery source and data storage unit, and looks similar to a small external hard drive.

As I’ve noted in previous stories in my series All About Skimmers, the emergence of this type of skimming attack is thought to be response to the widespread availability of third party anti-skimming technology which is successful at preventing the operation of a traditional skimmer placed on the outside of the ATM.

The Connecticut task task force notes that authorities there did not find hidden cameras or other methods of capturing customer PINs at the ATMs compromised by periscope skimmers, suggesting these attacks involved mere prototypes and that the thieves responsible are in the process of refining their technology.

Nevertheless, crooks who are serious about this type of crime eventually will want to capture your PIN so they can later drain your debit account at another ATM. So it’s important to remember that covering the PIN pad with your hand defeats the hidden camera from capturing your PIN. Occasionally, skimmer thieves will use PIN pad overlays, but these are comparatively rare and quite a bit more expensive; hidden cameras are used on the vast majority of the more than three dozen ATM skimming incidents that I’ve documented here.

Another periscope skimming device found at an ATM in Pennsylvania.
Shockingly, few people bother to take this simple, effective step, as detailed in this skimmer tale from 2012, wherein I obtained hours worth of video seized from two ATM skimming operations and saw customer after customer walk up, insert their cards and punch in their digits — all in the clear.

Many readers have asked whether the incidence of such skimming scams will decrease as more banks begin issuing more secure chip-based payment cards. The answer is probably not. That’s because even after most U.S. banks put in place chip-capable ATMs, the magnetic stripe will still be needed because it’s an integral part of the way ATMs work: Most ATMs in use today require a magnetic stripe for the card to be accepted into the machine.

The principal reason for this is to ensure that customers are putting the card into the slot correctly, as embossed letters and numbers running across odd spots in the card reader can take their toll on the machines over time. As long as the cardholder’s data remains stored on a chip card’s magnetic stripe, thieves will continue building and placing these types of skimmers.

Also, the thieves conducting these periscope skimming attacks don’t necessarily need a key to access the ATMs. As I’ve noted in past skimming stories, crooks who specialize in compromising ATMs with malicious software often target stand-alone cash machines that may be easier to access from the top-hat. My advice? Stick to ATMs that are installed in the wall at a bank or otherwise not exposed from the top.

Most importantly, watch out for your own physical safety while using an ATM. Keep your wits about you as you transact in and leave the area, and try to be keenly aware of your immediate surroundings. Use only machines in public, well-lit areas, and avoid ATMs in secluded spots.
Top

VirtualBox Shared Folders: progress report

Postby gonzo via FreeBSD developer's notebook | All Things FreeBSD »

I spent Labor Day weekend laboring on VBox shared folders support for FreeBSD. It’s been some time since I worked on it last time so I had to refresh my memory first. Things have moved on since then – VBox in ports was updated to version 5, but fortunately Li-Wen synced up freebsd-vboxfs repo to the latest version. After three days of laid-back hacking I am glad to announce that following VOPs are kind of implemented (in no particular order): lookup, access, readdir, read, getattr, readlink, remove, rmdir, symlink, close, create, open, write. “Kind of implemented” means that I was able to mount directory, traverse it, read file, calculate md5 sums and compare with host’s md5sum, create/remove directories, unzip zip file, etc but I doubt it would survive stress-test. Locking is all wrong at the moment and read/write VOPs allocate buffers for every operation.

I hit a roadblock with rename VOP: it involves some non-trivial locking logic and also there is a problem with cached paths. VBox hypervisor operates on full paths so we cache them in vboxfs nodes, but if one of parent directories is renamed, all cached names should be modified accordingly. I am going to tackle these two problems once I have long enough stretch of time time sit and concentrate on task.
Top

libarchive: bsdtar: stack-based buffer overflow in bsdtar_expand_char (util.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

This bug comes out after 5 days of fuzzing and when AFL reports that it already made 15 cycles. This means that in some cases is not enough do few hours of fuzzing and believe that there aren’t more bugs…

A crafted file causes a stack-buffer overflow write.
Upstream was not able to reproduce the issue, maybe different compiler and compiler options, so he committed the fix based on what the stacktrace printed. The bug is now not anymore reachable through the provided testcase, but I asked to make a new release to launch the fuzzer again.

The complete ASan output:

# bsdtar -t -f $FILE
bsdtar: Missing type keyword in mtree specification
5!\\{bsdtar: Missing type keyword in mtree specification

zO!\\{bsdtar: Missing type keyword in mtree specification

zO\r\r\\{bsdtar: Missing type keyword in mtree specification

zO\r\\w\200r\rbsdtar: Missing type keyword in mtree specification

@;\r\005@{bsdtar: Missing type keyword in mtree specification

zO\r\r\\{bsdtar: Malformed attribute "" (-51)

z\f\fbsdtar: Missing type keyword in mtree specification

h\352*((-.I,\002:%1=\037\257:B\362\020\217(\300\351!\002\341\341\341*(\244\244\263\377\377\377\377\244\377\177\244\244\244\244\244\244\244\264\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\244\036\036\036\036\036\036\036\036\036\036bsdtar: Missing type keyword in mtree specification
=================================================================
==6259==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fae139bf660 at pc 0x0000004957dc bp 0x7ffc9de91a90 sp 0x7ffc9de91240
WRITE of size 4 at 0x7fae139bf660 thread T0
    #0 0x4957db in vsprintf /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1128
    #1 0x495912 in sprintf /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1159
    #2 0x50ab22 in bsdtar_expand_char /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/util.c:223:4
    #3 0x509c47 in safe_fprintf /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/util.c:174:21
    #4 0x50307f in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:320:5
    #5 0x501bf3 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #6 0x4f8b9f in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #7 0x7fae1780761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #8 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

Address 0x7fae139bf660 is located in stack of thread T0 at offset 608 in frame
    #0 0x50964f in safe_fprintf /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/util.c:95

  This frame has 4 object(s):
    [32, 288) 'fmtbuff_stack'
    [352, 608) 'outbuff' 0x0ff64272fec0: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
  0x0ff64272fed0: f2 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 04 f3 f3 f3
  0x0ff64272fee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff64272fef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff64272ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff64272ff10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==6259==ABORTING
Affected version:
3.2.1

Fixed version:
Maybe in 3.2.2 (not yet released)

Commit fix:
https://github.com/libarchive/libarchive/commit/e37b620fe8f14535d737e89a4dcabaed4517bf1a

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-17: bug discovered
2016-08-17: bug reported to upstream
2016-08-21: upstream released a patch
2016-09-11: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar: stack-based buffer overflow in bsdtar_expand_char (util.c)

Top

libarchive: bsdtar use-after-free in detect_form (archive_read_support_format_mtree.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

A crafted file causes an use-after-free in the detect_form function in the mtree parser.

This bug seems to be similar to THIS use-after-free, but in this case ASan does not mention bid_entry.

The complete ASan output:

# bsdtar -t -f $FILE
==23484==ERROR: AddressSanitizer: heap-use-after-free on address 0x7fb5fce53b12 at pc 0x7fb5fc825bac bp 0x7ffe5622bb30 sp 0x7ffe5622bb28                                                       
READ of size 1 at 0x7fb5fce53b12 thread T0                                                                                                                                                     
    #0 0x7fb5fc825bab in detect_form /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:692:26                                 
    #1 0x7fb5fc6eb18b in choose_format /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:712:10                                                    
    #2 0x7fb5fc6eb18b in archive_read_open1 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:529                                                  
    #3 0x7fb5fc722f1f in archive_read_open_filename /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_open_filename.c:109:9                          
    #4 0x501f66 in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:223:6                                                                           
    #5 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #6 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #7 0x7fb5fb75e61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #8 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

0x7fb5fce53b12 is located 13074 bytes inside of 131072-byte region [0x7fb5fce50800,0x7fb5fce70800)
freed by thread T0 here:
    #0 0x4c29c0 in free /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:38
    #1 0x7fb5fc6f2c68 in __archive_read_filter_ahead /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:1450:5

previously allocated by thread T0 here:
    #0 0x4c2cc8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7fb5fc6f2bca in __archive_read_filter_ahead /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:1436:17

SUMMARY: AddressSanitizer: heap-use-after-free /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:692:26 in detect_form
Shadow bytes around the buggy address:
  0x0ff73f9c2710: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2720: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2730: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2740: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2750: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0ff73f9c2760: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c2790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c27a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0ff73f9c27b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==23484==ABORTING
Affected version:
3.2.1

Fixed version:
N/A

Commit fix:
https://github.com/libarchive/libarchive/commit/eec077f52bfa2d3f7103b4b74d52572ba8a15aca

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-11: bug discovered
2016-08-11: bug reported to upstream
2016-09-11: blog post about the issue
2016-09-19: upstream released a patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar use-after-free in detect_form (archive_read_support_format_mtree.c)

Top

libarchive: bsdtar use-after-free in bid_entry (archive_read_support_format_mtree.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

A crafted file causes an use-after-free in the bid_entry function in the mtree parser.

This bug seems to be similar to THIS use-after-free but in this case ASan reports that happens in the bid_entry function instead of detect_form.

The complete ASan output:

# bsdtar -t -f $FILE
==25892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f2eec8eb31b at pc 0x7f2eec2b9bb6 bp 0x7ffc198b3b30 sp 0x7ffc198b3b28
READ of size 1 at 0x7f2eec8eb31b thread T0
    #0 0x7f2eec2b9bb5 in bid_entry /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:567:7
    #1 0x7f2eec2b9bb5 in detect_form /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:676
    #2 0x7f2eec17f18b in choose_format /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:712:10
    #3 0x7f2eec17f18b in archive_read_open1 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:529
    #4 0x7f2eec1b6f1f in archive_read_open_filename /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_open_filename.c:109:9
    #5 0x501f66 in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:223:6
    #6 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #7 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #8 0x7f2eeb1f261f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

0x7f2eec8eb31b is located 27419 bytes inside of 131072-byte region [0x7f2eec8e4800,0x7f2eec904800)
freed by thread T0 here:
    #0 0x4c29c0 in free /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:38
    #1 0x7f2eec186c68 in __archive_read_filter_ahead /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:1450:5

previously allocated by thread T0 here:
    #0 0x4c2cc8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7f2eec186bca in __archive_read_filter_ahead /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:1436:17

SUMMARY: AddressSanitizer: heap-use-after-free /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:567:7 in bid_entry
Shadow bytes around the buggy address:
  0x0fe65d915610: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915620: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915640: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915650: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0fe65d915660: fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915670: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915680: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d915690: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d9156a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0fe65d9156b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==25892==ABORTING
Affected version:
3.2.1

Fixed version:
N/A

Commit fix:
https://github.com/libarchive/libarchive/commit/eec077f52bfa2d3f7103b4b74d52572ba8a15aca

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-11: bug discovered
2016-08-11: bug reported to upstream
2016-09-11: blog post about the issue
2016-09-19: upstream released a patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar use-after-free in bid_entry (archive_read_support_format_mtree.c)

Top

libarchive: bsdtar: heap-based buffer overflow in bid_entry (archive_read_support_format_mtree.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

A crafted file causes an heap overflow in the bid_entry function in the mtree parser.
This bug seems to be similar to THIS bug, but in this case ASan reports that the issue happens in the heap.

The complete ASan output:

# bsdtar -t -f $FILE
==786==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f3cae7e9a65 at pc 0x7f3cae1c0bb6 bp 0x7ffe4f21cb30 sp 0x7ffe4f21cb28
READ of size 1 at 0x7f3cae7e9a65 thread T0
    #0 0x7f3cae1c0bb5 in bid_entry /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:567:7
    #1 0x7f3cae1c0bb5 in detect_form /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:676
    #2 0x7f3cae08618b in choose_format /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:712:10
    #3 0x7f3cae08618b in archive_read_open1 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:529
    #4 0x7f3cae0bdf1f in archive_read_open_filename /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_open_filename.c:109:9
    #5 0x501f66 in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:223:6
    #6 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #7 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #8 0x7f3cad0f961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

0x7f3cae7e9a65 is located 613 bytes to the right of 262144-byte region [0x7f3cae7a9800,0x7f3cae7e9800)
allocated by thread T0 here:
    #0 0x4c2cc8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7f3cae08dbca in __archive_read_filter_ahead /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:1436:17

SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:567:7 in bid_entry
Shadow bytes around the buggy address:
  0x0fe815cf52f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe815cf5300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0fe815cf5340: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa
  0x0fe815cf5350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5360: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5370: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0fe815cf5390: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==786==ABORTING
Affected version:
3.2.1

Fixed version:
N/A

Commit fix:
https://github.com/libarchive/libarchive/commit/eec077f52bfa2d3f7103b4b74d52572ba8a15aca

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-11: bug discovered
2016-08-11: bug reported to upstream
2016-09-11: blog post about the issue
2016-09-19: upstream released a patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar: heap-based buffer overflow in bid_entry (archive_read_support_format_mtree.c)

Top

libarchive: bsdtar: memory corruption/unknown-crash in bid_entry (archive_read_support_format_mtree.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

A crafted file causes an heap overflow in the bid_entry function in the mtree parser.
This bug seems to be similar to THIS bug, but in this case ASan does not report the issue as in the heap.
Also, this bug was discovered by gsingh93 using the libarchive api.

The complete ASan output:

# bsdtar -t -f $FILE
==6147==ERROR: AddressSanitizer: unknown-crash on address 0x7fa7103c437b at pc 0x7fa70fd73bb6 bp 0x7ffc3948db30 sp 0x7ffc3948db28
READ of size 1 at 0x7fa7103c437b thread T0
    #0 0x7fa70fd73bb5 in bid_entry /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:567:7
    #1 0x7fa70fd73bb5 in detect_form /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:676
    #2 0x7fa70fc3918b in choose_format /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:712:10
    #3 0x7fa70fc3918b in archive_read_open1 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:529
    #4 0x7fa70fc70f1f in archive_read_open_filename /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_open_filename.c:109:9
    #5 0x501f66 in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:223:6
    #6 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #7 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #8 0x7fa70ecac61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

AddressSanitizer can not describe address in more detail (wild memory access suspected).
SUMMARY: AddressSanitizer: unknown-crash /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:567:7 in bid_entry
Shadow bytes around the buggy address:
  0x0ff562070810: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff562070820: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff562070830: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff562070840: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff562070850: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
=>0x0ff562070860: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe[fe]
  0x0ff562070870: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff562070880: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff562070890: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff5620708a0: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
  0x0ff5620708b0: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==6147==ABORTING
Affected version:
3.2.1

Fixed version:
N/A

Commit fix:
https://github.com/libarchive/libarchive/commit/eec077f52bfa2d3f7103b4b74d52572ba8a15aca

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.
This bug was discovered by gsingh93.

CVE:
N/A

Timeline:
2016-08-11: bug discovered
2016-08-11: bug reported to upstream
2016-09-11: blog post about the issue
2016-09-19: upstream released a patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar: memory corruption/unknown-crash in bid_entry (archive_read_support_format_mtree.c)

Top

libarchive: bsdtar: heap-based buffer overflow in read_Header (archive_read_support_format_7zip.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

A crafted file causes an heap overflow in the read_Header function in the 7zip parser.

The complete ASan output:

# bsdtar -t -f $FILE
==27481==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ecbb at pc 0x7f01eb0e55fc bp 0x7fff63005ad0 sp 0x7fff63005ac8
READ of size 1 at 0x60200000ecbb thread T0
    #0 0x7f01eb0e55fb in read_Header /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:2601:9
    #1 0x7f01eb0e55fb in slurp_central_directory /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:2923
    #2 0x7f01eb0e55fb in archive_read_format_7zip_read_header /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:638
    #3 0x7f01eb07a0ec in _archive_read_next_header2 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:649:7
    #4 0x7f01eb079c8f in _archive_read_next_header /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:687:8
    #5 0x5021cb in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:261:7
    #6 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #7 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #8 0x7f01ea0df61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

0x60200000ecbb is located 0 bytes to the right of 11-byte region [0x60200000ecb0,0x60200000ecbb)
allocated by thread T0 here:
    #0 0x4c2e50 in calloc /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66
    #1 0x7f01eb0dead3 in read_Header /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:2454:24
    #2 0x7f01eb0dead3 in slurp_central_directory /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:2923
    #3 0x7f01eb0dead3 in archive_read_format_7zip_read_header /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:638
    #4 0x7f01eb07a0ec in _archive_read_next_header2 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:649:7
    #5 0x7f01eb079c8f in _archive_read_next_header /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:687:8
    #6 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #7 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #8 0x7f01ea0df61f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289

SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_7zip.c:2601:9 in read_Header
Shadow bytes around the buggy address:
  0x0c047fff9d40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9d90: fa fa fa fa fa fa 00[03]fa fa fd fa fa fa fd fa
  0x0c047fff9da0: fa fa 04 fa fa fa 01 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff9db0: fa fa 00 fa fa fa 04 fa fa fa 01 fa fa fa 00 fa
  0x0c047fff9dc0: fa fa 00 fa fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x0c047fff9dd0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
  0x0c047fff9de0: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==27481==ABORTING
Affected version:
3.2.1

Fixed version:
N/A

Commit fix:
https://github.com/libarchive/libarchive/commit/7f17c791dcfd8c0416e2cd2485b19410e47ef126

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-11: bug discovered
2016-08-11: bug reported to upstream
2016-09-11: blog post about the issue
2016-09-19: upstream released a patch

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar: heap-based buffer overflow in read_Header (archive_read_support_format_7zip.c)

Top

libarchive: bsdtar: heap-based buffer overflow in detect_form (archive_read_support_format_mtree.c)

Postby ago via agostino's blog »

Description:
libarchive is a multi-format archive and compression library.

After it got fuzzed by hanno and some other people (1 2 3)I decided to fuzz it too.

A crafted file causes an heap overflow in the detect_form function in the mtree parser.

The complete ASan output:

# bsdtar -t -f $FILE
==25612==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fadef29981e at pc 0x7fadeec6fbac bp 0x7ffd2318bb30 sp 0x7ffd2318bb28                                                      
READ of size 1 at 0x7fadef29981e thread T0                                                                                                                                                     
    #0 0x7fadeec6fbab in detect_form /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:692:26                                 
    #1 0x7fadeeb3518b in choose_format /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:712:10                                                    
    #2 0x7fadeeb3518b in archive_read_open1 /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:529
    #3 0x7fadeeb6cf1f in archive_read_open_filename /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_open_filename.c:109:9
    #4 0x501f66 in read_archive /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:223:6
    #5 0x501473 in tar_mode_t /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/read.c:94:2
    #6 0x4f8929 in main /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/tar/bsdtar.c:803:3
    #7 0x7fadedba861f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #8 0x41b778 in _init (/usr/bin/bsdtar+0x41b778)

0x7fadef29981e is located 4126 bytes to the right of 262144-byte region [0x7fadef258800,0x7fadef298800)
allocated by thread T0 here:
    #0 0x4c2cc8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.0-r3/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52
    #1 0x7fadeeb3cbca in __archive_read_filter_ahead /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read.c:1436:17

SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/app-arch/libarchive-3.2.1-r3/work/libarchive-3.2.1/libarchive/archive_read_support_format_mtree.c:692:26 in detect_form
Shadow bytes around the buggy address:
  0x0ff63de4b2b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b2c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b2d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b2e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b2f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0ff63de4b300: fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0ff63de4b350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==25612==ABORTING
Affected version:
3.2.1

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-11: bug discovered
2016-08-11: bug reported to upstream
2016-09-11: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

libarchive: bsdtar: heap-based buffer overflow in detect_form (archive_read_support_format_mtree.c)

Top

Alleged vDOS Proprietors Arrested in Israel

Postby BrianKrebs via Krebs on Security »

Two young Israeli men alleged to be the co-owners of a popular online attack-for-hire service were reportedly arrested in Israel on Thursday. The pair were arrested around the same time that KrebsOnSecurity published a story naming them as the masterminds behind a service that can be hired to knock Web sites and Internet users offline with powerful blasts of junk data.

Alleged vDOS co-owner Yarden Bidani.
According to a story at Israeli news site TheMarker.comItay Huri and Yarden Bidani, both 18 years old, were arrested Thursday in connection with an investigation by the U.S. Federal Bureau of Investigation (FBI).

The pair were reportedly questioned and released Friday on the equivalent of about USD $10,000 bond each. Israeli authorities also seized their passports, placed them under house arrest for 10 days, and forbade them from using the Internet or telecommunications equipment of any kind for 30 days.

Huri and Bidani are suspected of running an attack service called vDOS. As I described in this week’s story, vDOS is a “booter” service that has earned in excess of $600,000 over the past two years helping customers coordinate more than 150,000 so-called distributed denial-of-service (DDoS) attacks designed to knock Web sites offline.

The two men’s identities were exposed because vDOS got massively hacked, spilling secrets about tens of thousands of paying customers and their targets. A copy of that database was obtained by KrebsOnSecurity.

For most of Friday, KrebsOnSecurity came under a heavy and sustained denial-of-service attack, which spiked at almost 140 Gbps. A single message was buried in each attack packet: “godiefaggot.” For a brief time the site was unavailable, but thankfully it is guarded by DDoS protection firm Prolexic/Akamai. The attacks against this site are ongoing.

Huri and Bidani were fairly open about their activities, or at least not terribly careful to cover their tracks. Yarden’s now abandoned Facebook page contains several messages from friends who refer to him by his hacker nickname “AppleJ4ck” and discuss DDoS activities. vDOS’s customer support system was configured to send a text message to Huri’s phone number in Israel — the same phone number that was listed in the Web site registration records for the domain v-email[dot]org, a domain the proprietors used to help manage the site.

At the end of August 2016, Huri and Bidani authored a technical paper (PDF) on DDoS attack methods which was published in the Israeli security e-zine Digital Whisper. In it, Huri signs his real name and says he is 18 years old and about to be drafted into the Israel Defense Forces. Bidani co-authored the paper under the alias “Raziel.b7@gmail.com,” an email address that I pointed out in my previous reporting was assigned to one of the administrators of vDOS.

Sometime on Friday, vDOS went offline. It is currently unreachable. Before it went offline, vDOS was supported by at least four servers hosted in Bulgaria at a provider called Verdina.net (the Internet address of those servers was 82.118.233.144). But according to several automated Twitter feeds that track suspicious large-scale changes to the global Internet routing tables, sometime in the last 24 hours vDOS was apparently the victim of what’s known as a BGP hijack. (Update: For some unknown reason, some of the tweets referenced above from BGPstream were deleted; I’ve archived them in this PDF).

BGP hijacking involves one ISP fraudulently “announcing” to the rest of the world’s ISPs that it is in fact the rightful custodian of a range of Internet addresses that it doesn’t actually have the right to control. It is a hack most often associated with spamming activity. According to those Twitter feeds, vDOS’s Internet addresses were hijacked by a firm called BackConnect Security.

Reached by phone, Bryant Townsend, founder and CEO of BackConnect Security, confirmed that his company did in fact hijack Verdina/vDOS’s Internet address space. Townsend said the company took the extreme measure in an effort to get out from under a massive attack launched on the company’s network Thursday, and that the company received an email directly from vDOS claiming credit for the attack.

“For about six hours, we were seeing attacks of more than 200 Gbps hitting us,” Townsend explained. “What we were doing was for defensive purposes. We were simply trying to get them to stop and to gather as much information as possible about the botnet they were using and report that to the proper authorities.”

I noted earlier this week that I would be writing more about the victims of vDOS. That story will have to wait for a few more days, but Friday evening CloudFlare (another DDoS protection service that vDOS was actually hiding behind) agreed to host the rather large log file listing roughly four months of vDOS attack logs from April through July 2016.

For some reason the attack logs only go back four months, probably because they were wiped at one point. But vDOS has been in operation since Sept. 2012, so this is likely a very small subset of the attacks this DDoS-for-hire service has perpetrated.

The file lists the vDOS username that ordered and paid for the attack; the target Internet address; the method of attack; the Internet address of the vDOS user at the time; the date and time the attack was executed; and the browser user agent string of the vDOS user.

A few lines from the vDOS attack logs.
Top

autotrace: heap-based buffer overflow in pstoedit_suffix_table_init (output-pstoedit.c)

Postby ago via agostino's blog »

Description:
autotrace is a program for converting bitmaps to vector graphics.

If compiled with Address Sanitizer, it shows that ANY bmp image causes an out-of-bounds write.

The complete ASan output:

# autotrace $FILE
==31756==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61700000ff20 at pc 0x7f11a5538380 bp 0x7ffecc970f90 sp 0x7ffecc970f88                                                      
WRITE of size 8 at 0x61700000ff20 thread T0                                                                                                                                                    
    #0 0x7f11a553837f in pstoedit_suffix_table_init /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/output-pstoedit.c:103:54                                              
    #1 0x7f11a5536544 in pstoedit_suffix_table_lookup_shallow /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/output-pstoedit.c:143:5                                     
    #2 0x7f11a5536544 in output_pstoedit_is_writer /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/output-pstoedit.c:160                                                  
    #3 0x7f11a556020b in at_splines_write /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/autotrace.c:375:7                                                               
    #4 0x4f579b in main /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/main.c:161:3                                                                                      
    #5 0x7f11a460761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #6 0x4196b8 in _init (/usr/bin/autotrace+0x4196b8)                                                                                                                                         
                                                                                                                                                                                               
0x61700000ff21 is located 0 bytes to the right of 673-byte region [0x61700000fc80,0x61700000ff21)                                                                                              
allocated by thread T0 here:                                                                                                                                                                   
    #0 0x4c0c08 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52                                                      
    #1 0x7f11a5538053 in pstoedit_suffix_table_init /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/output-pstoedit.c:87:7                                                
                                                                                                                                                                                               
SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/media-gfx/autotrace-0.31.1-r7/work/autotrace-0.31.1/output-pstoedit.c:103:54 in pstoedit_suffix_table_init                    
Shadow bytes around the buggy address:                                                                                                                                                         
  0x0c2e7fff9f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                              
  0x0c2e7fff9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                              
  0x0c2e7fff9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                              
  0x0c2e7fff9fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                              
  0x0c2e7fff9fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                              
=>0x0c2e7fff9fe0: 00 00 00 00[01]fa fa fa fa fa fa fa fa fa fa fa                                                                                                                              
  0x0c2e7fff9ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                              
  0x0c2e7fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                              
  0x0c2e7fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                              
  0x0c2e7fffa020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                              
  0x0c2e7fffa030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa                                                                                                                              
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==31756==ABORTING
Affected version:
0.31.1

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
CVE-2016-7392

Timeline:
2016-09-10: bug discovered
2016-09-10: bug reported to upstream
2016-09-10: blog post about the issue
2016-09-10: CVE assigned

Note:
This bug was found with Address Sanitizer.

Permalink:

autotrace: heap-based buffer overflow in pstoedit_suffix_table_init (output-pstoedit.c)

Top

ettercap: etterlog: NULL pointer dereference in fingerprint_search (ec_fingerprint.c)

Postby ago via agostino's blog »

Description:
ettercap is a comprehensive suite for man in the middle attacks.

Etterlog, which is part of the package, fails to read malformed data produced from the fuzzer and makes visible a NULL pointer access.

The complete ASan output:

# etterlog $FILE
Log file version    : 0.8.2                                                                                                                                                                    
Timestamp           : Thu Jul 16 15:28:54 2015 [688192]                                                                                                                                        
Type                : LOG_INFO                                                                                                                                                                 

1766 tcp OS fingerprint                                                                                                                                                                        

20530 mac vendor fingerprint                                                                                                                                                                   

2182 known services                                                                                                                                                                            

ASAN:DEADLYSIGNAL                                                                                                                                                                              
=================================================================                                                                                                                              
==9987==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f4671a428b2 bp 0x7ffd1cdbf5b0 sp 0x7ffd1cdbf540 T0)                                                             
    #0 0x7f4671a428b1 in fingerprint_search /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/src/ec_fingerprint.c:189:17                                                             
    #1 0x7f4671a6ee4e in print_host /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/src/ec_passive.c:120:8                                                                          
    #2 0x4fe769 in display_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:277:10                                                                  
    #3 0x4fe769 in display /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:52                                                                           
    #4 0x507818 in main /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_main.c:94:4                                                                               
    #5 0x7f46706e561f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #6 0x41a408 in _start (/usr/bin/etterlog+0x41a408)                                                                                                                                         

AddressSanitizer can not provide additional info.                                                                                                                                              
SUMMARY: AddressSanitizer: SEGV /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/src/ec_fingerprint.c:189:17 in fingerprint_search                                                   
==9987==ABORTING                                                                                                                                                                               

etterlog 0.8.2 copyright 2001-2015 Ettercap Development Team                                                                                                                                   



==================================================
 IP address   : 192.168.0.31 

 MAC address  : 34:17:EB:9B:21:AD 
 MANUFACTURER : Dell Inc 

 DISTANCE     : 0   
 TYPE         : LAN host

 FINGERPRINT      : �
Affected version:
0.8.2

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-10: bug discovered
2016-08-11: bug reported to upstream
2016-09-09: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.
The stacktrace is about a git version compiled when I reported the bug to upstream, but is reproducible with 0.8.2 too.

Permalink:

ettercap: etterlog: NULL pointer dereference in fingerprint_search (ec_fingerprint.c)

Top

Israeli Online Attack Service ‘vDOS’ Earned $600,000 in Two Years

Postby BrianKrebs via Krebs on Security »

vDOS  a “booter” service that has earned in excess of $600,000 over the past two years helping customers coordinate more than 150,000 so-called distributed denial-of-service (DDoS) attacks designed to knock Web sites offline — has been massively hacked, spilling secrets about tens of thousands of paying customers and their targets.

The vDOS database, obtained by KrebsOnSecurity.com at the end of July 2016, points to two young men in Israel as the principal owners and masterminds of the attack service, with support services coming from several young hackers in the United States.

The vDos home page.
To say that vDOS has been responsible for a majority of the DDoS attacks clogging up the Internet over the past few years would be an understatement. The various subscription packages to the service are sold based in part on how many seconds the denial-of-service attack will last. And in just four months between April and July 2016, vDOS was responsible for launching more than 277 million seconds of attack time, or approximately 8.81 years worth of attack traffic.

Let the enormity of that number sink in for a moment: That’s nearly nine of what I call “DDoS years” crammed into just four months. That kind of time compression is possible because vDOS handles hundreds — if not thousands — of concurrent attacks on any given day.

Although I can’t prove it yet, it seems likely that vDOS is responsible for several decades worth of DDoS years. That’s because the data leaked in the hack of vDOS suggest that the proprietors erased all digital records of attacks that customers launched between Sept. 2012 (when the service first came online) and the end of March 2016.

HOW vDOS GOT HACKED

The hack of vDOS came about after a source was investigating a vulnerability he discovered on a similar attack-for-hire service called PoodleStresser. The vulnerability allowed my source to download the configuration data for PoodleStresser’s attack servers, which pointed back to api.vdos-s[dot]com. PoodleStresser, as well as a large number of other booter services, appears to rely exclusively on firepower generated by vDOS.

From there, the source was able to exploit a more serious security hole in vDOS that allowed him to dump all of the service’s databases and configuration files, and to discover the true Internet address of four rented servers in Bulgaria (at Verdina.net) that are apparently being used to launch the attacks sold by vDOS. The DDoS-for-hire service is hidden behind DDoS protection firm Cloudflare, but its actual Internet address is 82.118.233.144.

vDOS had a reputation on cybercrime forums for prompt and helpful customer service, and the leaked vDOS databases offer a fascinating glimpse into the logistical challenges associated with running a criminal attack service online that supports tens of thousands of paying customers — a significant portion of whom are all trying to use the service simultaneously.

Multiple vDOS tech support tickets were filed by customers who complained that they were unable to order attacks on Web sites in Israel. Responses from the tech support staff show that the proprietors of vDOS are indeed living in Israel and in fact set the service up so that it was unable to attack any Web sites in that country — presumably so as to not attract unwanted attention to their service from Israeli authorities. Here are a few of those responses:

(‘4130′,’Hello `d0rk`,\r\nAll Israeli IP ranges have been blacklisted due to security reasons.\r\n\r\nBest regards,\r\nP1st.’,’03-01-2015 08:39),

(‘15462′,’Hello `g4ng`,\r\nMh, neither. I\’m actually from Israel, and decided to blacklist all of them. It\’s my home country, and don\’t want something to happen to them :)\r\n\r\nBest regards,\r\nDrop.’,’11-03-2015 15:35),

(‘15462′,’Hello `roibm123`,\r\nBecause I have an Israeli IP that is dynamic.. can\’t risk getting hit/updating the blacklist 24/7.\r\n\r\nBest regards,\r\nLandon.’,’06-04-2015 23:04),

(‘4202′,’Hello `zavi156`,\r\nThose IPs are in israel, and we have all of Israel on our blacklist. Sorry for any inconvinience.\r\n\r\nBest regards,\r\nJeremy.’,’20-05-2015 10:14),

(‘4202′,’Hello `zavi156`,\r\nBecause the owner is in Israel, and he doesn\’t want his entire region being hit offline.\r\n\r\nBest regards,\r\nJeremy.’,’20-05-2015 11:12),

(‘9057′,’There is a option to buy with Paypal? I will pay more than $2.5 worth.\r\nThis is not the first time I am buying booter from you.\r\nIf no, Could you please ask AplleJack? I know him from Israel.\r\nThanks.’,’21-05-2015 12:51),

(‘4120′,’Hello `takedown`,\r\nEvery single IP that\’s hosted in israel is blacklisted for safety reason. \r\n\r\nBest regards,\r\nAppleJ4ck.’,’02-09-2015 08:57),

WHO RUNS vDOS?

As we can see from the above responses from vDOS’s tech support, the owners and operators of vDOS are young Israeli hackers who go by the names P1st a.k.a. P1st0, and AppleJ4ck. The two men market their service mainly on the site hackforums[dot]net, selling monthly subscriptions using multiple pricing tiers ranging from $20 to $200 per month. AppleJ4ck hides behind the same nickname on Hackforums, while P1st goes by the alias “M30w” on the forum.

Some of P1st/M30W’s posts on Hackforums regarding his service vDOS.
vDOS appears to be the longest-running booter service advertised on Hackforums, and it is by far and away the most profitable such business. Records leaked from vDOS indicate that since July 2014, tens of thousands of paying customers spent a total of more than $618,000 at the service using Bitcoin and PayPal.

Incredibly, for brief periods the site even accepted credit cards in exchange for online attacks, although it’s unclear how much the site might have made in credit card payments because the information is not in the leaked databases.

The Web server hosting vDOS also houses several other sites, including huri[dot]biz, ustress[dot]io, and vstress[dot]net. Virtually all of the administrators at vDOS have an email account that ends in v-email[dot]org, a domain that also is registered to an Itay Huri with a phone number that traces back to Israel.

The proprietors of vDOS set their service up so that anytime a customer asked for technical assistance the site would blast a text message to six different mobile numbers tied to administrators of the service, using an SMS service called Nexmo.com. Two of those mobile numbers go to phones in Israel. One of them is the same number listed for Itay Huri in the Web site registration records for v-email[dot]org; the other belongs to an Israeli citizen named Yarden Bidani. Neither individual responded to requests for comment.

The leaked database and files indicate that vDOS uses Mailgun for email management, and the secret keys needed to manage that Mailgun service were among the files stolen by my source. The data shows that vDOS support emails go to itay@huri[dot]biz, itayhuri8@gmail.com and raziel.b7@gmail.com.

LAUNDERING THE PROCEEDS FROM DDOS ATTACKS

The $618,000 in earnings documented in the vDOS leaked logs is almost certainly a conservative income figure. That’s because the vDOS service actually dates back to Sept 2012, yet the payment records are not available for purchases prior to 2014. As a result, it’s likely that this service has made its proprietors more than $1 million.

vDOS does not currently accept PayPal payments. But for several years until recently it did, and records show the proprietors of the attack service worked assiduously to launder payments for the service through a round-robin chain of PayPal accounts.

They did this because at the time PayPal was working with a team of academic researchers to identify, seize and shutter PayPal accounts that were found to be accepting funds on behalf of booter services like vDOS. Anyone interested in reading more on their success in making life harder for these booter service owners should check out my August 2015 story, Stress-Testing the Booter Services, Financially.

People running dodgy online services that violate PayPal’s terms of service generally turn to several methods to mask the true location of their PayPal Instant Payment Notification systems. Here is an interesting analysis of how popular booter services are doing so using shell corporations, link shortening services and other tricks.

Turns out, AppleJ4ck and p1st routinely recruited other forum members on Hackforums to help them launder significant sums of PayPal payments for vDOS each week.

“The paypals that the money are sent from are not verified,” AppleJ4ck says in one recruitment thread. “Most of the payments will be 200$-300$ each and I’ll do around 2-3 payments per day.”

vDos co-owner AppleJ4ck recruiting Hackforums members to help launder PayPal payments for his booter service.
It is apparent from the leaked vDOS logs that in July 2016 the service’s owners implemented an additional security measure for Bitcoin payments, which they accept through Coinbase. The data shows that they now use an intermediary server (45.55.55.193) to handle Coinbase traffic. When a Bitcoin payment is received, Coinbase notifies this intermediary server, not the actual vDOS servers in Bulgaria.

A server situated in the middle and hosted at a U.S.-based address from Digital Ocean then updates the database in Bulgaria, perhaps because the vDOS proprietors believed payments from the USA would attract less interest from Coinbase than huge sums traversing through Bulgaria each day.

ANALYSIS

The extent to which the proprietors of vDOS went to launder profits from the service and to obfuscate their activities clearly indicate they knew that the majority of their users were using the service to knock others offline.

Defenders of booter and stresser services argue the services are legal because they can be used to help Web site owners stress-test their own sites and to build better defenses against such attacks. While it’s impossible to tell what percentage of vDOS users actually were using the service to stress-test their own sites, the leaked vDOS logs show that a huge percentage of the attack targets are online businesses.

In reality, the methods that vDOS uses to sustain its business are practically indistinguishable from those employed by organized cybercrime gangs, said Damon McCoy, an assistant professor of computer science at New York University.

“These guys are definitely taking a page out of the playbook of the Russian cybercriminals,” said McCoy, the researcher principally responsible for pushing vDOS and other booter services off of PayPal (see the aforementioned story Stress-Testing the Booter Services, Financially for more on this).

“A lot of the Russian botnet operators who routinely paid people to infect Windows computers with malware used to say they wouldn’t buy malware installs from Russia or CIS countries,” McCoy said. “The main reason was they didn’t want to make trouble in their local jurisdiction in the hopes that no one in their country would be a victim and have standing to bring a case against them.”

The service advertises attacks at up to 50 gigabits of data per second (Gbps). That’s roughly the equivalent of trying to cram two, high-definition Netflix movies down a target’s network pipe all at the same moment.

But Allison Nixon, director of security research at business risk intelligence firm Flashpoint, said her tests of vDOS’s service generated attacks that were quite a bit smaller than that — 14 Gbps and 6 Gbps. Nevertheless, she noted, even an attack that generates just 6 Gbps is well more than enough to cripple most sites which are not already protected by anti-DDoS services.

And herein lies the rub with services like vDOS: They put high-powered, point-and-click cyber weapons in the hands of people — mostly young men in their teens — who otherwise wouldn’t begin to know how to launch such attacks. Worse still, they force even the smallest of businesses to pay for DDoS protection services or else risk being taken offline by anyone with a grudge or agenda.

“The problem is that this kind of firepower is available to literally anyone willing to pay $30 a month,” Nixon said. “Basically what this means is that you must have DDoS protection to participate on the Internet. Otherwise, any angry young teenager is going to be able to take you offline in a heartbeat. It’s sad, but these attack services mean that DDoS protection has become the price of admission for running a Web site these days.”

Stay tuned for the next piece in this series on the hack of vDOS, which will examine some of the more interesting victims of this service.
Top

The Limits of SMS for 2-Factor Authentication

Postby BrianKrebs via Krebs on Security »

A recent ping from a reader reminded me that I’ve been meaning to blog about the security limitations of using cell phone text messages for two-factor authentication online. The reader’s daughter had received a text message claiming to be from Google, warning that her Gmail account had been locked because someone in India had tried to access her account. The young woman was advised to expect a 6-digit verification code to be sent to her and to reply to the scammer’s message with that code.

Mark Cobb, a computer technician in Reno, Nev., said had his daughter fallen for the ruse, her Gmail account would indeed have been completely compromised, and she really would have been locked out of her account because the crooks would have changed her password straight away.

Cobb’s daughter received the scam text message because she’d enabled 2-factor authentication on her Gmail account, selecting the option to have Google request that she enter a 6-digit code texted to her cell phone each time it detects a login from an unknown computer or location (in practice, the code is to be entered on the Gmail site, not sent in any kind of texted or emailed reply).

In this case, the thieves already had her password — most likely because she re-used it on some other site that got hacked. Cobb says he and his daughter believe her mobile number and password may have been exposed as part of the 2012 breach at LinkedIn.

In any case, the crooks were priming her to expect a code and to repeat it back to them because that code was the only thing standing in the way of their seizing control over her account. And they could control when Google would send the code to her phone because Google would do this as soon as they tried to log in using her username and password. Indeed, the timing aspect of this attack helps make it more believable to the target.

This is a fairly clever — if not novel — attack, and it’s one I’d wager would likely fool a decent percentage of users who have enabled text messages as a form of two-factor authentication. Certainly, text messaging is far from the strongest form of 2-factor authentication, but it is better than allowing a login with nothing more than a username and password, as this scam illustrates.

Nevertheless, text messaging codes to users isn’t the safest way to do two-factor authentication, even if some entities — like the U.S. Social Security Administration and Sony’s Playstation network — are just getting around to offering two-factor via SMS.

But don’t take my word for it. That’s according to the National Institute of Standards and Technology (NIST), which recently issued new proposed digital authentication guidelines urging organizations to favor other forms of two-factor — such as time-base one-time passwords generated by mobile apps — over text messaging. By the way, NIST is seeking feedback on these recommendations.

If anyone’s interested, Sophos’s Naked Security blog has a very readable breakdown of what’s new in the NIST guidelines. Among my favorite highlights is this broad directive: Favor the user.

“To begin with, make your password policies user friendly and put the burden on the verifier when possible,” Sophos’s Chester Wisniewski writes. “In other words, we need to stop asking users to do things that aren’t actually improving security.” Like expiring passwords and making users change them frequently, for example.

Okay, so the geeks-in-chief are saying it’s time to move away from texting as a form of 2-factor authentication. And, of course, they’re right, because text messages are a lot like email, in that it’s difficult to tell who really sent the message, and the message itself is sent in plain text — i.e. is readable by anyone who happens to be lurking in the middle.

But security experts and many technology enthusiasts have a tendency to think that everyone should see the world through the lens of security, whereas most mere mortal users just want to get on with their lives and are perfectly content to use the same password across multiple sites — regardless of how many times they’re told not to do so.

Google’s new push-based two-factor authentication system. Image: Google.
Indeed, while many more companies now offer some form of two-factor authentication than did two or three years ago — consumer adoption of this core security feature remains seriously lacking. For example, the head of security at Dropbox recently told KrebsOnSecurity that less than one percent of its user base of 500 million registered users had chosen to turn on 2-factor authentication for their accounts. And Dropbox isn’t exactly a Johnny-come-lately to the 2-factor party: It has been offering 2-factor logins for a full four years now.

I doubt Dropbox is somehow an aberration in this regard, and it seems likely that other services also suffer from single-digit two-factor adoption rates. But if more consumers haven’t enabled two-factor options, it’s probably because a) it’s still optional and b) it still demands too much caring and understanding from the user about what’s going on and how these security systems can be subverted.

Personally, I favor app-based time-based one-time password (TOTP) systems like Google Authenticator, which continuously auto-generates a unique code via a mobile-based app.

Google recently went a step further along the lines of where I’d like to see two-factor headed across the board, by debuting a new “push” authentication system that generates a prompt on the user’s mobile device that users need to tap to approve login requests. This is very similar to another push-based two-factor system I’ve long used and trusted — from Duo Security [full disclosure: Duo is an advertiser on this site].

For a comprehensive breakdown of which online services offer two-factor authentication and of what type, check out twofactorauth.org. And bear in mind that even if text-based authentication is all that’s offered, that’s still better than nothing. What’s more, it’s still probably more security than the majority of the planet has protecting their accounts.
Top

libav: null pointer dereference in mpeg4video_probe (m4vdec.c)

Postby ago via agostino's blog »

Description:
Libav is an open source set of tools for audio and video processing.

A crafted file causes a NULL pointer access. The ASan report may be confused because it mention get_vlc2, but the issue is in mpeg4video_probe.
This issue was discovered the past year, but I didn’t make the report and I didn’t follow the state because of a lack of time.

In the meantime the bug was reported by thomas.nowotny on the libav bugtracker. Since his build was not compiled with ASan and he didn’t check with tools like valgrind, nobody noticed the NULL pointer access. Instead, avconv just printed “Invalid data found when processing input”.

The complete ASan output:

# avconv -i $FILE -f null -
ASAN:SIGSEGV
=================================================================
==20876==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000fc (pc 0x7f5273202c6c bp 0x7ffc8442a690 sp 0x7ffc8442a520 T0)
    #0 0x7f5273202c6b in get_vlc2 /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/get_bits.h:530:5
    #1 0x7f5273202c6b in mpeg4_decode_sprite_trajectory /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/mpeg4videodec.c:182
    #2 0x7f527322cbd8 in decode_vop_header /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/mpeg4videodec.c:2232:13
    #3 0x7f527322cbd8 in ff_mpeg4_decode_picture_header /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/mpeg4videodec.c:2491
    #4 0x7f52731fa9ae in mpeg4_decode_header /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/mpeg4video_parser.c:92:11
    #5 0x7f52731fa9ae in mpeg4video_parse /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/mpeg4video_parser.c:132
    #6 0x7f52735c88e6 in av_parser_parse2 /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/parser.c:157:13
    #7 0x7f52754f84dd in parse_packet /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavformat/utils.c:794:15
    #8 0x7f52754d5e64 in read_frame_internal /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavformat/utils.c:960:24
    #9 0x7f52754e3783 in avformat_find_stream_info /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavformat/utils.c:2156:15
    #10 0x4f62f6 in open_input_file /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv_opt.c:726:11
    #11 0x4f474f in open_files /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv_opt.c:2127:15
    #12 0x4f3f62 in avconv_parse_options /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv_opt.c:2164:11
    #13 0x528727 in main /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv.c:2629:11
    #14 0x7f527027eaa4 in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20/csu/libc-start.c:289
    #15 0x43a5d6 in _start (/usr/bin/avconv+0x43a5d6)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/get_bits.h:530 get_vlc2
==20876==ABORTING
Affected version:
11.7 (and maybe past versions)

Fixed version:
master (no release atm)

Commit fix:
https://git.libav.org/?p=libav.git;a=commit;h=v12_dev0-3071-ge5b0197

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.
This bug was discovered by thomas.nowotny as a normal bug.

CVE:
N/A

Timeline:
2015-07-27: bug discovered
2016-07-06: bug filed on the libav bugtracker
2016-07-31: upstream released a patch
2016-08-25: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.
This bug does not affect ffmpeg.
If you see v11.3 in the trace is because I saved it when I discovered the bug, but is reproducible with 11.7 too. So there is no mistake in the affected version.

Permalink:
https://blogs.gentoo.org/ago/2016/08/25/libav-null-pointer-dereference-in-mpeg4video_probe-m4vdec-c
Top

graphicsmagick: NULL pointer dereference in MagickStrlCpy (utility.c)

Postby ago via agostino's blog »

Description:
Graphicsmagick is an Image Processing System.

A fuzzing revealed a NULL pointer access in the TIFF parser.

The complete ASan output:

# gm identify $FILE
ASAN:DEADLYSIGNAL
=================================================================
==19028==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fbd36dd6c3c bp 0x7ffe3c007090 sp 0x7ffe3c006d10 T0)
    #0 0x7fbd36dd6c3b in MagickStrlCpy /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/utility.c:4567:3
    #1 0x7fbd2b714c26 in ReadTIFFImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/coders/tiff.c:2048:13
    #2 0x7fbd36ac506a in ReadImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1607:13
    #3 0x7fbd36ac46ac in PingImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1370:9
    #4 0x7fbd36a165a0 in IdentifyImageCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8372:17
    #5 0x7fbd36a1affb in MagickCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8862:17
    #6 0x7fbd36a6fee3 in GMCommandSingle /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17370:10
    #7 0x7fbd36a6eb78 in GMCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17423:16
    #8 0x7fbd3597761f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #9 0x4188d8 in _init (/usr/bin/gm+0x4188d8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/utility.c:4567:3 in MagickStrlCpy
==19028==ABORTING
Affected version:
1.3.24 (and maybe past)

Fixed version:
1.3.25

Commit fix:
http://hg.code.sf.net/p/graphicsmagick/code/rev/eb58028dacf5

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-17: bug discovered
2016-08-18: bug reported privately to upstream
2016-08-19: upstream released a patch
2016-09-05: upstream released 1.3.25
2016-09-07: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

graphicsmagick: NULL pointer dereference in MagickStrlCpy (utility.c)

Top

Congressional Report Slams OPM on Data Breach

Postby BrianKrebs via Krebs on Security »

The massive data breach at the U.S. Office of Personnel Management (OPM) that exposed background investigations and fingerprint data on millions of Americans was the result of a cascading series of cybersecurity blunders from the agency’s senior leadership on down to the outdated technology used to secure the sensitive data, according to a lengthy report released today by a key government oversight panel.

OPM offices in Washington, DC. Image: Flickr.
The 241-page analysis, commissioned by the U.S. House Oversight & Government Reform Committee, blames OPM for jeopardizing U.S. national security for more than a generation.

The report offers perhaps the most exhaustive accounting and timeline of the breach since it was first publicly disclosed in mid-2015. According to the document, the lax state of OPM’s information security left the agency’s information systems exposed for any experienced hacker to infiltrate and compromise.

“The agency’s senior leadership failed to fully comprehend the extent of the compromise, allowing the hackers to remove manuals and other sensitive materials that essentially provided a roadmap to the OPM IT environment and key users for potential compromise,” the report charges.

Probably the most incisive portion of the assessment is the timeline of major events in the breach, which details a series of miscalculations on the part of the OPM leadership. The analysis paints the picture of a chronic — almost willful — underestimation by senior leadership at OPM about the seriousness of the threat facing the agency, until it was too late.

According to the report, the OPM first learned something was amiss on March 20, 2014, when the US-CERT notified the agency of data being exfiltrated from its network. In the ensuing weeks, OPM worked with US-CERT to implement a strategy to monitor the attackers’ movements to gather counterintelligence.

The only problem with this plan, according to the panel, was that the agency erroneously believed it had cornered the intruder. However, the hacker that OPM and US-CERT had eyes on wasn’t alone. While OPM monitored the first hacker [referred to in the report only as Hacker X1] on May 7, 2014 another hacker posed as an employee of an OPM contractor (Keypoint) performing background investigations. That intruder, referred to as Hacker X2, used the contractor’s OPM credentials to log into the OPM system, install malware and create a backdoor to the network.

As the agency monitored Hacker X1’s movements through the network, the committee found, it noticed hacker X1 was getting dangerously close to the security clearance background information. OPM, in conjunction with DHS, quickly developed a plan to kick Hacker X1 out of its system. It termed this remediation “the Big Bang.” At the time, the agency was confident the planned remediation effort on May 27, 2014 eliminated Hacker X1’s foothold on their systems.

The decision to execute the Big Bang plan was made after OPM observed the attacker load keystroke logging malware onto the workstations of several database administrators, the panel found.

“But Hacker X2, who had successfully established a foothold on OPM’s systems and had not been detected due to gaps in OPM’s security posture, remained in OPM’s systems post-Big Bang,” the report notes.

On June 5, malware was successfully installed on a KeyPoint Web server. After that, X2 moved around OPM’s system until July 29, 2014, when the intruders registered opmlearning.org — a domain the attackers used as a command-and-control center to manage their malware operations.

Beginning in July through August 2014, the Hacker X2 exfiltrated the security clearance background investigation files. Then in December 2014, 4.2 million personnel records were exfiltrated.

On March 3, 2015, wdc-news-post[dot]com was registered by the attackers, who used it as a command-and-control network. On March 26, 2015, the intruders begin stealing fingerprint data.

The committee found that had the OPM implemented basic, required security controls and more expeditiously deployed cutting edge security tools when they first learned hackers were targeting such sensitive data, they could have significantly delayed, potentially prevented, or significantly mitigated the theft.

For example, “OPM’s adoption of two-factor authentication for remote logons in early 2015, which had long been required of federal agencies, would have precluded continued access by the intruder into the OPM network,” the panel concluded.

Unfortunately, the exact details on how and when the attackers gained entry and established a persistent presence in OPM’s network are not entirely clear, the committee charges.

“This is in large part due to sloppy cyber hygiene and inadequate security technologies that left OPM with reduced visibility into the traffic on its systems,” the report notes. “The data breach by Hacker X1 in 2014 should have sounded a high level, multi-agency national security alarm that a sophisticated, persistent actor was seeking to access OPM’s highest-value data. It wasn’t until April 15, 2015 that the OPM identified the first indicator that its systems were compromised by Hacker X2.”

The information stolen in the breach included detailed files and personal background reports on more than 21.5 million individuals, and fingerprint data on 5.6 million of these individuals. Those security clearance background reports often included extremely sensitive information, such as whether applicants had consulted with a health care professional regarding an emotional or mental health condition; illegally used any drugs or controlled substances; experienced financial problems due to gambling.

The intrusion, widely attributed to hackers working with the Chinese government, likely pointed out which federal employees working for the U.S. State Department were actually spies trained by the U.S. Central Intelligence Agency. That’s because — unlike most federal agencies — the CIA conducted its own background checks on potential employees, and did not manage the process through the OPM.

As The Washington Post pointed out in September 2015, the CIA ended up pulling a number of officers from its embassy in Beijing in the wake of the OPM breach, mainly because the data leaked in the intrusion would have let the Chinese government work out which State Department employees stationed there were not listed in the background check data stolen from the OPM.

As bad and as total as the OPM breach has been, it’s remarkable how few security experts I’ve heard raise the issue of what might be at stake if the OPM plunderers had not simply stolen data, but also manipulated it.

Not long after congressional hearings began on the OPM breach, I heard from a source in the U.S. intelligence community who wondered why nobody was asking this question: If the attackers could steal all of this sensitive data and go undetected for so long, could they not also have granted security clearances to people who not only didn’t actually warrant them, but who might have been recruited in advance to work for the attackers? To this date, I’ve not heard a good answer to this question.

A copy of the 110 mb report is available here (PDF).
Top

This week in vc4 (2016-09-06): glmark2, X testing, kernel maintaining

Postby Eric Anholt via anholt's lj »

Last week I was tasked with making performance comparisons between vc4 and the closed driver possible.  I decided to take glmark2 and port it to dispmanx, and submitted a pull request upstream.  It already worked on X11 on the vc4 driver, and I fixed the drm backend to work as well (though the drm backend has performance problems specific to the glmark2 code).

Looking at glmark2, vc4 has a few bugs.  Terrain has some rendering bugs.  The driver on master took a big performance hit on one of the conditionals tests since the loops support was added, because NIR isn't aggressive enough in flattening if statements.  Some of the tests require that we shuffle rendering jobs to avoid extra frame store/loads.  Finally, we need to use the multithreaded fragment shader mode to hide texture fetching latency on a bunch of tests.  Despite the bugs, results looked good.

(Note: I won't be posting comparisons here.  Comparisons will be left up to the reader on their particular hardware and software stacks).

I'm expecting to get to do some glamor work on vc4 again soon, so I spent some of the time while I was waiting for Raspberry Pi builds working on the X Server's testing infrastructure.  I've previously talked about Travis CI, but for it to be really useful it needs to run our integration tests.  I fixed up the piglit XTS test wrapper to not spuriously fail, made the X Test suite spuriously fail less, and worked with Adam Jackson at Red Hat to fix build issues in XTS.  Finally, I wrote scripts that will, if you have an XTS tree and a piglit tree and build Xvfb, actually run the XTS rendering tests at xserver make check time.

Next steps for xserver testing are to test glamor in a similar fashion, and to integrate this testing into travis-ci and land the travis-ci branch.

Finally, I submitted pull requests to the upstream kernel.  4.8 got some fixes for VC4 3D (merged by Dave), and 4.9 got interlaced vblank timing patches from the Mario Kleiner (not yet merged by Dave) and Raspberry Pi Zero (merged by Florian).
Top

ettercap: etterlog: multiple (three) heap-based buffer overflow (el_profiles.c)

Postby ago via agostino's blog »

Description:
ettercap is a comprehensive suite for man in the middle attacks.

Etterlog, which is part of the package, fails to read malformed data produced from the fuzzer and then it overflows.

Since there are three issues, to make it short, I’m cutting a bit the ASan output.

# etterlog $FILE
==10077==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e00000dac0 at pc 0x00000047b8cf bp 0x7ffdc6850580 sp 0x7ffdc684fd30                                                      
READ of size 43780 at 0x60e00000dac0 thread T0                                                                                                                                                 
    #0 0x47b8ce in memcmp /var/tmp/temp/portage/sys-devel/llvm-3.8.0-r2/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:418            
    #1 0x50e26e in profile_add_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:106:12                                                             
    #2 0x4f3d3a in create_hosts_list /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_analyze.c:128:7                                                              
    #3 0x4fcf0c in display_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:218:4                                                                   
    #4 0x4fcf0c in display /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:52                                                                           
    #5 0x507818 in main /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_main.c:94:4                                                                               
    #6 0x7faa8656161f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #7 0x41a408 in _start (/usr/bin/etterlog+0x41a408)                                                                                                                                         

0x60e00000dac0 is located 0 bytes to the right of 160-byte region [0x60e00000da20,0x60e00000dac0)                                                                                              
allocated by thread T0 here:                                                                                                                                                                   
    #0 0x4c1ae0 in calloc /var/tmp/temp/portage/sys-devel/llvm-3.8.0-r2/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66                                              
    #1 0x50e215 in profile_add_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:99:4                                                               


==10144==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000efa0 at pc 0x00000047b8cf bp 0x7ffe22881090 sp 0x7ffe22880840
READ of size 256 at 0x60600000efa0 thread T0
    #0 0x47b8ce in memcmp /var/tmp/temp/portage/sys-devel/llvm-3.8.0-r2/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:418
    #1 0x50ff6f in update_user_list /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:251:12
    #2 0x50e555 in profile_add_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:91:10
    #3 0x4f3d3a in create_hosts_list /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_analyze.c:128:7
    #4 0x4fcf0c in display_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:218:4
    #5 0x4fcf0c in display /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:52
    #6 0x507818 in main /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_main.c:94:4
    #7 0x7f53a781461f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #8 0x41a408 in _start (/usr/bin/etterlog+0x41a408)

0x60600000efa0 is located 0 bytes to the right of 64-byte region [0x60600000ef60,0x60600000efa0)
allocated by thread T0 here:
    #0 0x4c1ae0 in calloc /var/tmp/temp/portage/sys-devel/llvm-3.8.0-r2/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66
    #1 0x50ffea in update_user_list /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:256:4


==10212==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e00000de40 at pc 0x00000047b8cf bp 0x7ffe0a6b9460 sp 0x7ffe0a6b8c10
READ of size 37636 at 0x60e00000de40 thread T0
    #0 0x47b8ce in memcmp /var/tmp/temp/portage/sys-devel/llvm-3.8.0-r2/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:418
    #1 0x50e1a3 in profile_add_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:89:12
    #2 0x4f3d3a in create_hosts_list /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_analyze.c:128:7
    #3 0x4fcf0c in display_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:218:4
    #4 0x4fcf0c in display /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_display.c:52
    #5 0x507818 in main /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_main.c:94:4
    #6 0x7f562119261f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289
    #7 0x41a408 in _start (/usr/bin/etterlog+0x41a408)

0x60e00000de40 is located 0 bytes to the right of 160-byte region [0x60e00000dda0,0x60e00000de40)
allocated by thread T0 here:
    #0 0x4c1ae0 in calloc /var/tmp/temp/portage/sys-devel/llvm-3.8.0-r2/work/llvm-3.8.0.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66
    #1 0x50e215 in profile_add_info /tmp/portage/net-analyzer/ettercap-9999/work/ettercap-9999/utils/etterlog/el_profiles.c:99:4
Affected version:
0.8.2

Fixed version:
N/A

Commit fix:
N/a

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-10: bug discovered
2016-08-11: bug reported to upstream
2016-09-06: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.
The stacktrace is about a git version compiled when I reported the bug to upstream, but is reproducible with 0.8.2 too.

Permalink:

ettercap: etterlog: multiple (three) heap-based buffer overflow (el_profiles.c)

Top

4.9 == next LTS kernel

Postby Greg Kroah-Hartman via Linux Kernel Monkey Log »

As I briefly mentioned a few weeks ago on my G+ page, the plan is for the 4.9 Linux kernel release to be the next “Long Term Supported” (LTS) kernel.

Last year, at the Linux Kernel Summit, we discussed just how to pick the LTS kernel. Many years ago, we tried to let everyone know ahead of time what the kernel version would be, but that caused a lot of problems as people threw crud in there that really wasn’t ready to be merged, just to make it easier for their “day job”. That was many years ago, and people insist they aren’t going to do this again, so let’s see what happens.

I reserve the right to not pick 4.9 and support it for two years, if it’s a major pain because people abused this notice. If so, I’ll possibly drop back to 4.8, or just wait for 4.10 to be released. I’ll let everyone know by updating the kernel.org releases page when it’s time (many months from now.)

If people have questions about this, email me and I will be glad to discuss it.
Top

GStreamer on Android and universal builds

Postby Arun via Arun Raghavan »

This is a quick PSA for those of you using the GStreamer binary builds for Android.

With the Android NDK r12, the default behaviour while building native code changed from building for armeabi to building for all ABIs. So if your app doesn’t specify APP_ABI in its Application.mk, you will now get an error about unsupported architectures. This was tracked as bug 770631.

The idea behind this change is that your Android app should ship versions of your native code for all supported architectures as a “universal” build, so it is accessible to as many devices as possible.

To deal with this, we now provide a universal tarball which contains binaries for all archiectures that we support. This is currently ARM, ARMv7-A, ARMv8-A (64-bit), x86, and x86-64. That leaves MIPS and MIPS64 that are not currently supported.

If you’ve been using the GStreamer Android binaries before GStreamer 1.9.2, then you should start using the universal tarball rather than the architecture-specific tarball. You will need minor updates to your native build, like we made to the player example. You probably want to put the gstAndroidRoot variable in ~/.gradle/gradle.properties instead, though.

As Sebastian announced, assuming all goes well with the universal tarballs, we will stop shipping the per-arch tarballs — they are redundant, and just take up CI and disk resources.

There are some things that I’d like for us to be able to do better. The first is that Android Studio doesn’t pick up native code with our current build approach. This is a limitation of the Android Gradle NDK plugin, which doesn’t support a custom build. This should change with Android Studio 2.2.

I would also like to integrate better with Android Studio — either be able to specify the GStreamer Android binary path in the UI (like you do for the SDK/NDK), or better yet, have it be possible to specify the dependency in Gradle, and have it be automatically pulled from the Internet. If any of you are familiar with how we can do this, please shout out!
Top

Location Privacy: The Purview of the Rich and Indigent

Postby BrianKrebs via Krebs on Security »

I’d just finished parking my car in the covered garage at Reagan National Airport just across the river from Washington, D.C. when I noticed a dark green minivan slowly creeping through the row behind me. The vehicle caught my attention because its driver didn’t appear to be looking for an open spot. What’s more, the van had what looked like two cameras perched atop its roof — one of each side, both pointed down and slightly off to the side.

I had a few hours before my flight boarded, so I delayed my walk to the terminal and cut through several rows of cars to snag a video of the guy moving haltingly through another line of cars. I approached the driver and asked what he was doing. He smiled and tilted the lid on his bolted-down laptop so that I could see the pictures he was taking with the mounted cameras: He was photographing every license plate in the garage (for the record, his plate was a Virginia tag number 36-646L).

A van at Reagan National Airport equipped with automated license plate readers fixed to the roof.
The man said he was hired by the airport to keep track of the precise location of every car in the lot, explaining that the data is most often used by the airport when passengers returning from a trip forget where they parked their vehicles. I checked with the Metropolitan Washington Airports Authority (MWAA), which manages the garage, and they confirmed the license plate imaging service was handled by a third-party firm called HUB Parking.

I’m accustomed to having my license plate photographed when entering a parking area (Dulles International Airport in Virginia does this), but until that encounter at Reagan National I never considered that this was done manually.

“Reagan National uses this service to assist customers in finding their lost vehicles,” said MWAA spokesperson Kimberly Gibbs. “If the customer remembers their license plate it can be entered into the system to determine what garages and on what aisle their vehicle is parked.”

What does HUB Parking do with the information its clients collect? Ilaria Riva, marketing manager for HUB Parking, says the company does not sell or share the data it collects, and that it is up to the client to decide how that information is stored or shared.

“It is true the solution that HUB provides to our clients may collect data, but HUB does not own the data nor do we have any control over what the customer does with it,” Riva said.

Gibbs said MWAA does not share parking information with outside organizations. But make no mistake: the technology used at Reagan National Airport, known as automated license plate reader or ALPR systems, is already widely deployed by municipalities, police forces and private companies — particularly those in the business of repossessing vehicles from deadbeat owners who don’t pay their bills.

It’s true that people have zero expectation of privacy in public places — and roads and parking garages certainly are public places for the most part. But according to the Electronic Frontier Foundation (EFF), the data collected by ALPR systems can be very revealing, and in many cities ALPR technology is rapidly outpacing the law.

“By matching your car to a particular time, date and location, and then building a database of that information over time, law enforcement can learn where you work and live, what doctor you go to, which religious services you attend, and who your friends are,” the EFF warns.

A 2014 ABC News investigation in Los Angeles found the technology broadly in use by everyone from the local police to repo men. The story notes that there are little or no restrictions on what private companies that collect time- and location-stamped license plate data can do with the information. As a result, they are selling it to insurers, banks, law enforcement and federal agencies.

In Texas, the EFF highlights how state and local law enforcement agencies have free access to ALPR equipment and license plate data maintained by a private company called Vigilant Solutions. In exchange, police cruisers are retrofitted with credit-card machines so that law enforcement officers can take payments for delinquent fines and other charges on the spot — with a 25 percent processing fee tacked on that goes straight to Vigilant. In essence, the driver is paying Vigilant to provide the local cops with the technology used to identify and detain the driver.

“The ‘warrant redemption’ program works like this,” the EFF wrote. “The agency is given no-cost license plate readers as well as free access to LEARN-NVLS, the ALPR data system Vigilant says contains more than 2.8-billion plate scans and is growing by more than 70-million scans a month. This also includes a wide variety of analytical and predictive software tools. Also, the agency is merely licensing the technology; Vigilant can take it back at any time.”

That’s right: Even if the contract between the state and Vigilant ends, the latter gets to keep all of the license plate data collected by the agency, and potentially sell or license the information to other governments or use it for other purposes.

I wanted to write this story not because it’s particularly newsy, but because I was curious about a single event and ended up learning a great deal that I didn’t already know about how pervasive this technology has become.

Yes, we need more transparency about what companies and governments are doing with information collected in public. But here’s the naked truth: None of us should harbor any illusions about maintaining the privacy of our location at any given moment — particularly in public spaces.

As it happens, location privacy is a considerably expensive and difficult goal for most Americans to attain and maintain. Our mobile phones are constantly pinging cell towers, making it simple for mobile providers and law enforcement agencies to get a fix on your location within a few dozen meters.

Obscuring the address of your residence is even harder. If you’ve ever had a mortgage on your home or secured utilities for your residence using your own name, chances are excellent that your name and address are in thousands of databases, and can be found with a free or inexpensive public records search online.

Increasingly, location privacy is the exclusive purview of two groups of Americans: Those who are indigent and/or homeless and those who are wealthy. Only the well-off can afford the substantial costs and many petty inconveniences associated with separating one’s name from their address, vehicle, phone records and other modern niceties that make one easy to track and find.
Top

‘Flash Hijacks’ Add New Twist to Muggings

Postby BrianKrebs via Krebs on Security »

A frequent crime in Brazil is a scheme in which thieves kidnap people as they’re leaving a bank, and free them only after visiting a number of ATMs to withdraw cash. Now the crooks have introduced a new time-saving wrinkle into this scam: In these so-called “flash hijacks” the thieves pull out a wireless card reader, swipe a few debit transactions with the victim’s card, and then release the individual.

A story in the Brazilian newspaper Liberal documents one such recent flash hijacking, involving two musicians in their 20s who were accosted by a pair of robbers — one of whom was carrying a gun. The thieves forced the victims to divulge their debit card personal identification numbers (PINs), and then proceeded to swipe the victim’s cards on a handheld, wireless card machine.

First spotted in 2015, flash hijackings are becoming more common in Brazil, said Paulo Brito, a cybersecurity expert living in the Campinas area of Brazil. Brito said even his friend’s son was similarly victimized recently.

“Of course transactions can be traced as far as they are done with Brazilian banks, but these bad guys can evolve and transact with foreign banks,” Brito said.


I suppose it’s slightly less traumatic for the victim if the use of handheld machines by the crooks mean victims have a gun to their heads for a shorter duration. It’s also nice that the thieves are bringing the theft to the victim, instead of the other way around.

In any case, these attacks underscore a major point I try to make when adding updates to my All About Skimmers series: Most of us are far more likely to get mugged after withdrawing money from an ATM or bank than we are to encounter a skimming device in real life.

The most important security advice is to watch out for your own physical safety while using an ATM. Keep your wits about you as you transact in and leave the area, and try to be keenly aware of your immediate surroundings. Use only machines in public, well-lit areas, and avoid ATMs in secluded spots. Also, cover the PIN pad with your hand when entering your PIN: That way, if even if the thieves somehow skim your card, there is less chance that they will be able to snag your PIN as well.
Top

RethinkDB on Gentoo Linux

Postby ultrabug via Ultrabug »



It was about time I added a new package to portage and I’m very glad it to be RethinkDB and its python driver !

  • dev-db/rethinkdb
  • dev-python/python-rethinkdb
For those of you who never heard about this database, I urge you to go about their excellent website and have a good read.

Packaging RethinkDB

RethinkDB has been under my radar for quite a long time now and when they finally got serious enough about high availability I also got serious about using it at work… and obviously “getting serious” + “work” means packaging it for Gentoo Linux

Quick notes on packaging for Gentoo Linux:

  • This is a C++ project so it feels natural and easy to grasp
  • The configure script already offers a way of using system libraries instead of the bundled ones which is in line with Gentoo’s QA policy
  • The only grey zone about the above statement is the web UI which is used precompiled
RethinkDB has a few QA violations which the ebuild is addressing by modifying the sources:

  • There is a configure.default which tries to force some configure options
  • The configure is missing some options to avoid auto installing some docs and init scripts
  • The build system does its best to guess the CXX compiler but it should offer an option to set it directly
  • The build system does not respect users’ CXXFLAGS and tries to force the usage of -03

Getting our hands into RethinkDB

At work, we finally found the excuse to get our hands into RethinkDB when we challenged ourselves with developing a quizz game for our booth as a sponsor of Europython 2016.

It was a simple game where you were presented a question and four possible answers and you had 60 seconds to answer as much of them as you could. The trick is that we wanted to create an interactive game where the participant had to play on a tablet but the rest of the audience got to see who was currently playing and follow their score progression + their ranking for the day and the week in real time on another screen !

Another challenge for us in the creation of this game is that we only used technologies that were new to us and even switched jobs so the backend python guys would be doing the frontend javascript et vice et versa. The stack finally went like this :

  • Game quizz frontend : Angular2 (TypeScript)
  • Game questions API : Go
  • Real time scores frontend : Angular2 + autobahn
  • Real time scores API : python 3.5 asyncio + autobahn
  • Database : RethinkDB
As you can see on the stack we chose RethinkDB for its main strength : real time updates pushed to the connected clients. The real time scores frontend and API were bonded together using autobahn while the API was using the changefeeds (realtime updates coming from the database) and broadcasting them to the frontend.

What we learnt about RethinkDB

  • We’re sure that we want to use it in production !
  • The ReQL query language is a pipeline so its syntax is quite tricky to get familiar with (even more when coming from mongoDB like us), it is as powerful as it can be disconcerting
  • Realtime changefeeds have limitations which are sometimes not so easy to understand/find out (especially the order_by / secondary index part)
  • Changefeeds limitations is a constraint you have to take into account in your data modeling !
  • Changefeeds + order_by can do the ordering for you when using the include_offsets option, this is amazing
  • The administration web UI is awesome
  • The python 3.5 asyncio proper support is still not merged, this is a pain !

Try it out

Now that you can emerge rethinkdb I encourage you to try this awesome database.

Be advised that the ebuild also provides a way of configuring your rethinkdb instance by running emerge –config dev-db/rethinkdb !

I’ll now try to get in touch with upstream to get Gentoo listed on their website.
Top

PC-BSD Evolves into TrueOS

Postby Josh Smith via Official PC-BSD Blog »

Official announcement for all PC-BSD users.  Please take a moment and check out this article.

PC-BSD Evolves into TrueOS

Top

Kimpton Hotels Acknowledges Data Breach

Postby BrianKrebs via Krebs on Security »

Kimpton Hotels on Wednesday formally acknowledged that malware found on payment terminals in many of its hotels and restaurants may have compromised credit/debit cards of guests who patronized the properties in the first half of this year. The disclosure comes more than a month after KrebsOnSecurity first contacted to the company about a possible credit card breach across most of its locations.

According to a notice added to the Kimpton Web site, the incident involved cards used at certain restaurants and hotel front desks from February 16, 2016 to July 7, 2016. Kimpton has posted a list of more than 60 restaurants and hotels where the company found and removed card-stealing malicious software from payment terminals.

Kimpton joins a long list of hotel brands that have acknowledged card breaches over the last year after prompting by KrebsOnSecurity, including Trump Hotels (twice), Hilton, Mandarin Oriental, and White Lodging (twice). Breaches also have hit hospitality chains Starwood Hotels and Hyatt.

In many of those incidents, thieves had planted malicious software on the point-of-sale devices at restaurants and bars inside of the hotel chains. However, the source and extent of the apparent breach at Kimpton properties is still unknown.

Point-of-sale based malware has driven most of the credit card breaches over the past two years, including intrusions at Target and Home Depot, as well as breaches at a slew of point-of-sale vendors. The malware usually is installed via hacked remote administration tools. Once the attackers have their malware loaded onto the point-of-sale devices, they can remotely capture data from each card swiped at that cash register.

Thieves can then sell the data to crooks who specialize in encoding the stolen data onto any card with a magnetic stripe, and using the cards to buy gift cards and high-priced goods from big-box stores like Target and Best Buy.

Readers should remember that they’re not liable for fraudulent charges on their credit or debit cards, but they still have to report the unauthorized transactions. There is no substitute for keeping a close eye on your card statements. Also, consider using credit cards instead of debit cards; having your checking account emptied of cash while your bank sorts out the situation can be a hassle and lead to secondary problems (bounced checks, for instance).
Top

This week in vc4 (2016-08-29): derivatives, GPU hangs, testing, kernel maintaining

Postby Eric Anholt via anholt's lj »

I spent a day or so last week cleaning up @jonasarrow's demo patch for derivatives on vc4.  It had been hanging around on the github issue waiting for a rework due to feedback, and I decided to finally just go and do it.  It unfortunately involved totally rewriting their patches (which I dislike doing, it's always more awesome to have the original submitter get credit), but we now have dFdx()/dFdy() on Mesa master.

I also landed a fix for GPU hangs with 16 vertex attributes (4 or more vec4s, aka glsl-routing in piglit).  I'd been debugging this one for a while, and finally came up with an idea ("what if this FIFO here is a bad idea to use and we should be synchronous with this external unit?"), it worked, and a hardware developer confirmed that the fix was correct.  This one got a huge explanation comment.  I also fixed discards inside of if/loop statements -- generally discards get lowered out of ifs, but if it's in a non-unrolled loop we were doing discards ignoring whether the channel was in the loop.

Thanks to review from Rhys, I landed Mesa's Travis build fixes.  Rhys then used Travis to test out a couple of fixes to i915 and r600.  This is pretty cool, but it just makes me really want to get piglit into Travis so that we can get some actual integration testing in this process.

I got xserver's Travis to the point of running the unit tests, and one of them crashes on CI but not locally.  That's interesting.

The last GPU hang I have in piglit is in glsl-vs-loops.  This week I figured out what's going on, and I hope I'll be able to write about a fix next week.

Finally, I landed Stefan Wahren's Raspberry Pi Zero devicetree for upstream.  If nothing goes wrong, the Zero should be supported in 4.9.
Top

potrace: memory allocation failure

Postby ago via agostino's blog »

Description:
potrace is a utility that transforms bitmaps into vector graphics.

A crafted image, through a fuzz testing, causes the memory allocation to fail.

Since the ASan symbolyzer didn’t start up correctly, I’m reporting only what it prints at the end.

# potrace $FILE
potrace: warning: 2.hangs: premature end of file
==13660==ERROR: AddressSanitizer failed to allocate 0x200003000 (8589946880) bytes of LargeMmapAllocator (error code: 12)
==13660==AddressSanitizer CHECK failed: /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:183 "((0 && "unable to mmap")) != (0)" (0x0, 0x0)
Affected version:
1.13

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-26: bug discovered
2016-08-27: bug reported privately to upstream
2016-08-29: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

potrace: memory allocation failure

Top

potrace: NULL pointer dereference in findnext (decompose.c)

Postby ago via agostino's blog »

Description:
potrace is a utility that transforms bitmaps into vector graphics.

A crafted image revealed, through a fuzz testing, the presence of a NULL pointer access.

The complete ASan output:

# potrace $FILE
potrace: warning: 48.crashes: premature end of file                                                                                                                                            
ASAN:DEADLYSIGNAL                                                                                                                                                                              
=================================================================                                                                                                                              
==13940==ERROR: AddressSanitizer: SEGV on unknown address 0x7fd7b865b800 (pc 0x7fd7ec5bcbf4 bp 0x7fff9ebad590 sp 0x7fff9ebad360 T0)                                                            
    #0 0x7fd7ec5bcbf3 in findnext /var/tmp/portage/media-gfx/potrace-1.13/work/potrace-1.13/src/decompose.c:436:11                                                                             
    #1 0x7fd7ec5bcbf3 in getenv /var/tmp/portage/media-gfx/potrace-1.13/work/potrace-1.13/src/decompose.c:478                                                                                  
    #2 0x7fd7ec5c3ed9 in potrace_trace /var/tmp/portage/media-gfx/potrace-1.13/work/potrace-1.13/src/potracelib.c:76:7                                                                         
    #3 0x4fea6e in process_file /var/tmp/portage/media-gfx/potrace-1.13/work/potrace-1.13/src/main.c:1102:10                                                                                   
    #4 0x4f872b in main /var/tmp/portage/media-gfx/potrace-1.13/work/potrace-1.13/src/main.c:1250:7                                                                                            
    #5 0x7fd7eb4d961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #6 0x418fc8 in getenv (/usr/bin/potrace+0x418fc8)                                                                                                                                          
                                                                                                                                                                                               
AddressSanitizer can not provide additional info.                                                                                                                                              
SUMMARY: AddressSanitizer: SEGV /var/tmp/portage/media-gfx/potrace-1.13/work/potrace-1.13/src/decompose.c:436:11 in findnext                                                                   
==13940==ABORTING
Affected version:
1.13

Fixed version:
N/A

Commit fix:
N/A

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-26: bug discovered
2016-08-27: bug reported privately to upstream
2016-08-29: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.

Permalink:

potrace: NULL pointer dereference in findnext (decompose.c)

Top

Food photography

Postby Dennis Klein via DieTa.Photo - Medium »



In the last days, I used Instagram a lot more than normally. When I started using it, I was wondering “why the hell should someone use it…

Continue reading on DieTa.Photo »
Top

HostSailor Threatens to Sue KrebsOnSecurity

Postby BrianKrebs via Krebs on Security »

Earlier this month, KrebsOnSecurity published The Reincarnation of a Bulletproof Hoster, which examined evidence suggesting that a Web hosting company called HostSailor was created out of the ashes of another, now-defunct hosting firm notorious for harboring spammers, scammers and other online ne’er-do-wells. Today, HostSailor’s lawyers threatened to sue this author unless the story is removed from the Web.

Obviously, I stand by my reporting and have no intention of unpublishing stories. But I’m writing about HostSailor again here because I promised to post an update if they ever responded to my requests for comment.

The letter, signed by Abdullah Alzarooni Advocates in Dubai — where HostSailor says it is based — carries the subject line, “Warning from Acts of Extortion and Abuse of the Privacy of Third Parties.” It lists a number of links to content the company apparently finds objectionable.

Could this same kind of legal pressure be why security industry giant Trend Micro removed all reference to HostSailor from the report that started all this? Trend hasn’t responded to direct questions about that.

Astute readers will notice in the letter (pasted below) a link to a Twitter message from this author among the many things HostSailor’s lawyers will like me to disappear from the Internet. That tweet to HostSailor’s Twitter account read:

“Potential downside of reporting ISIS sites: The hosting firm (ahem @HostSailor) may share your info/name/report with ISIS. Opsec, people!”

I sent that tweet after hearing from a source with whom I’ve been working to report sites affiliated with the jihadist militant group ISIS. The source had reported to HostSailor several of its Internet addresses that were being used by a propaganda site promoting videos of beheadings and other atrocities by ISIS, and he shared emails indicating that HostSailor had simply forwarded his abuse email on to its customer — complete with my source’s name and contact information. Thankfully, he was using a pseudonym and throwaway email address.

HostSailor’s twitter account responded by saying that the company doesn’t share information about its customers. But of course my tweet was regarding information shared about someone who is not a HostSailor customer.

This isn’t the first time KrebsOnSecurity has been threatened with lawsuits over stories published here. The last time I got one of these letters was in Sept. 2015, from a lawyer representing AshleyMadison’s former chief technology officer. The year before, it was Sony Pictures Entertainment, whose lawyers lashed out a large number of publications for too closely covering its epic and unprecedented data breach in 2014.

Prior to that, I received some letters from the lawyers for Igor Gusev, one of the main characters in my book, Spam Nation. Mr. Gusev’s attorneys insisted that I was publishing stolen information — pictures of him, financial records from his spam empire “SpamIt” — and demanded that I remove all offending items and publish an apology.

My attorney in that instance laughed out loud when I shared the letter from Gusev’s lawyers, calling it a “blivit.” When I apparently took more than a moment to get the joke, he explained that a “blivit” is a term coined by the late great author Kurt Vonnegut, who defined it as “two pounds of shit in a one-pound bag.”

Only time will tell if this letter is a blivit as well. I’ve taken the liberty of sanitizing the PDF document it came in, and converting that into two image files – in case anyone wants to take a look.

An emailed “legal notice” I apparently received from a law firm in Dubai, demanding that I unpublish an unflattering story about HostSailor.
Top

Inside ‘The Attack That Almost Broke the Internet’

Postby BrianKrebs via Krebs on Security »

In March 2013, a coalition of spammers and spam-friendly hosting firms pooled their resources to launch what would become the largest distributed denial-of-service (DDoS) attack the Internet had ever witnessed. The assault briefly knocked offline the world’s largest anti-spam organization, and caused a great deal of collateral damage to innocent bystanders in the process. Here’s a never-before-seen look at how that attack unfolded, and a rare glimpse into the shadowy cybercrime forces that orchestrated it.

The following are excerpts taken verbatim from a series of Skype and IRC chat room logs generated by a group of “bullet-proof cybercrime hosts” — so called because they specialized in providing online hosting to a variety of clientele involved in spammy and scammy activities.

Facebook profile picture of Sven Olaf Kamphuis
Gathered under the banner ‘STOPhaus,’ the group included a ragtag collection of hackers who got together on the 17th of March 2013 to launch what would quickly grow to a 300+Gigabits per second (Gbps) attack on Spamhaus.org, an anti-spam organization that they perceived as a clear and present danger to their spamming operations.

The attack –a stream of some 300 billion bits of data per second — was so large that it briefly knocked offline Cloudflare, a company that specializes in helping organizations stay online in the face of such assaults. Cloudflare dubbed it “The Attack that Almost Broke the Internet.

The campaign was allegedly organized by a Dutchman named Sven Olaf Kamphuis (pictured above). Kamphuis ran a company called CB3ROB, which in turn provided services for a Dutch company called “Cyberbunker,” so named because the organization was housed in a five-story NATO bunker and because it had advertised its services as a bulletproof hosting provider.

Kamphuis seemed to honestly believe his Cyberbunker was sovereign territory, even signing his emails “Prince of Cyberbunker Republic.” Arrested in Spain in April 2013 in connection with the attack on Spamhaus, Kamphuis was later extradited to The Netherlands to stand trial. He has publicly denied being part of the attacks and his trial is ongoing.

According to investigators, Kamphuis began coordinating the attack on Spamhaus after the anti-spam outfit added to its blacklist several of Cyberbunker’s Internet address ranges. The following logs, obtained by one of the parties to the week-long offensive, showcases the planning and executing of the DDoS attack, including digital assaults on a number of major Internet exchanges. The record also exposes the identities and roles of each of the participants in the attack.

The logs below are excerpts from a much longer conversation. The entire, unedited chat logs are available here. The logs are periodically broken up by text in italics, which includes additional context about each snippet of conversation. Also please note that the logs below may contain speech that some find offensive.

====================================================================

THE CHAT LOG MEMBERS
————————————————————
Aleksey Frolov : vainet[dot]biz, vainet[dot].ru, Russian host.
————————————————————
Alex Optik : Russian ‘BP host’. AKA NEO
————————————————————
Andrei Stanchevici : secured[dot]md Moldova
————————————————————
Cali : Vitalii Boiko AKA Vitaliyi Boyiko AKA Cali Yhzar, alleged by Spamhaus to be dedicated crime hosters urdn[dot]com.ua AKA Xentime[dot]com AKA kurupt[dot]ru
————————————————————
Darwick : Zemancsik Zsolt, 23net[dot]hu, Hungarian host.
————————————————————
eDataKing : Andrew Jacob Stephens, Ohio/Florida based spamware seller formerly listed on Spamhaus’s Register of Known Spam Operations (ROKSO). Was main social media mouthpiece of Stophaus (e.g. see @stophaus). Andrew threatens to sue everyone for libel, and is likely to show up in the comments below and do the same here.
————————————————————
Erik Bais : A2B Internet, Netherlands
————————————————————
Goo : Peter van Gorkum AKA Gooweb.nl, alleged by Spamhaus to be a botnet supplier in the Netherlands.
————————————————————
Hephaistos : AKA @AnonOps on Twitter
————————————————————
HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: Sven Olaf Kamphuis
AKA Cyberbunker AKA CB3ROB
————————————————————
Karlin König : Suavemente/SplitInfinity, San Diego based host.
————————————————————
marceledler : German hoster that Spamhaus says has a history of hosting spammers, AKA Optimate-Server[dot]de
————————————————————
Mark – Evgeny Pazderin : Russian, alleged by Spamhaus to be hoster of webinjects used for man-in-the-middle attacks (MITM) against online banking sessions.
————————————————————
Mastermind of Possibilities : Norman “Chris” Jester AKA Suavemente/SplitInfinity, alleged by Spamhaus to be San Diego based spam host.
————————————————————
Narko :Sean Nolan McDonough, UK-based teenager, trigger man in the attack. Allegedly hired by Yuri to perform the DDoS. Later pleaded guilty to coordinating the attack in 2013.
————————————————————
NM : Nikolay Metlyuk, according to Spamhaus a Russian botnet provider
————————————————————
simomchen : Simon Chen AKA idear4business counterfeit Chinese products, formerly listed on Spamhaus ROKSO.
————————————————————
Spamahost : As its name suggests, a Russian host specializing in spam, spam and spam.
————————————————————
twisted : Admin of Cyberbunker[dot]com
————————————————————
valeralelin : Valerii Lolin, infiumhost[dot]com, Ukraine
————————————————————
Valeriy Uhov : Per Spamhaus, a Russian ‘bulletproof hoster’.
————————————————————
WebExxpurts : Deepak Mehta, alleged cybercrime host specializing in hosting botnet C&Cs. AKA Turbovps (<bd[at]turbovps[dot]com>).
————————————————————
wmsecurity : off-sho[dot]re ‘Bulletproof’ hoster. Lithuania. AKA “Antitheist”. Profiled in this story.
————————————————————
Xennt : H.J. Xennt, owner of Cyberbunker.
————————————————————
Yuri : Yuri Bogdanov, owner of 2×4[dot]ru. According to Spamhaus, 2×4[dot]ru is a longtime spam friendly Russian host, formerly part of Russian Business Network (RBN). Allegedly hired Narko to launch DDoS attack against Spamhaus.
============================================================

[17.03.2013 19:51:31] eDataKing: watch the show: http://www.webhostingtalk.com/showthread.php?t=1247982
[17.03.2013 19:52:02] -= Darwick =-: hell yeah!
[17.03.2013 19:52:09] -= Darwick =-: hit them hard
[17.03.2013 19:54:07] -= Darwick =-: is that a ddos attack?
[17.03.2013 19:54:56] eDataKing: but let’s forget what it is and focus on it’s consequence lol

====================================================================

A number of chat members chastise eDataKing for incessantly posting comments to what they refer to as “nanae,” a derisive reference to the venerable USENET anti-spam list (news.admin.net-abuse.email) that focused solely on exposing spammers and their spamming activities. eDataKing is flustered and posting on nanae with rapid-fire, emotional replies to anti-spammers, but his buddies don’t want that kind of attention to their cause.

[17.03.2013 20:27:57] Mastermind of Possibilities: Andrew why are you posting in nanae? Stop man lol

====================================================================

Some of the chat participants begin debating whether they should consider adopting residence in a country that does not play well with the United States in terms of extradition.

[18.03.2013 02:28:30] eDataKing: what about a place that takes an ex-felon from the US for citizenship or expat?

====================================================================

The plotters begin running scans to find misconfigured or ill-protected systems that can be enslaved in attacks. They’re scanning the Web for domain name servers (DNS) systems that can be used to amplify and disguise or “reflect” the source of their attacks. Narko warns Sven about trying to enlist servers hosted by Dutch ISP Leaseweb, which was known to anticipate such activity and re-route attack traffic back to the true source of the traffic.

[18.03.2013 16:39:22] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: is just global transit thats filtered with them
[18.03.2013 16:39:33] narko: they change the ip back to your real server ip
[18.03.2013 16:39:38] narko: you will ddos your own server if you try this attack at leaseweb
[18.03.2013 16:39:46] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: hmm
[18.03.2013 16:39:50] Antitheist: what about root.lu?
[18.03.2013 16:39:54] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: very creative of them
[18.03.2013 16:39:55] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[18.03.2013 16:40:21] Antitheist: and nforce
18.03.2013 16:49:22] Antitheist: i host many cc shops, they even appeared on krebs blog
[18.03.2013 16:49:27] narko: where?

At around 4 p.m. GMT that same day, Sven announces that the group’s various cyber armies had succeeded in knocking Spamhaus off the Internet. Incredibly, Sven advertises his involvement with the group to all 3,850 of his Facebook friends.

17.03.2013 22:30:01] my 3850 facebook friends " class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" /> www.spamhaus.org still down, and that criminal bunch of self declared internet dictators will still remain down, until our demands are met " class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" /> over 48h already " class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" /> resolving your shit. end of the line buddy " class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" />" class="wp-smiley" style="height: 1em; max-height: 1em;" /> should have called and paid for the damages.
[17.03.2013 22:25:54] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: rokso no longer exists haha
[17.03.2013 22:29:51] Mastermind of Possibilities: Where is that posted ?
[17.03.2013 22:30:01] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: my 3850 facebook friends
[17.03.2013 22:30:12] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: you know, stuff people actually -use-… unlike smtp and nntp
[17.03.2013 22:30:12] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[17.03.2013 22:30:23] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP:facebook.com/cb3rob

====================================================================

Spamhaus uses a friendly blog — Wordtothewise.com — to publish an alert that it is “under major dDos.” While Spamhaus is offline, various parties to the attack begin hatching ways to take advantage by poisoning search-engine results so that when one searches for “Spamhaus,” the first several results instead redirect to Stophaus[dot]org, the forum this group set up to coordinate the attacks.



18.03.2013 13:09:09] Alex Optik:http://www.stopspamhaus.org/2013_02_01_archive.html
[18.03.2013 13:09:35] Alex Optik: as i see there is already has same projects
[18.03.2013 13:09:59] narko: (wave)
[18.03.2013 13:10:17] eDataKing: that site is owned by a person in this group Alex
stealing seo to bump spamhaus while it’s offline 3 days
[18.03.2013 16:14:14] Antitheist: do you mind if we put spamhaus metatags on stophaus?
[18.03.2013 16:14:24] Antitheist: so we can come up first on google soon
file fake info alert to ICANN
[18.03.2013 16:26:45] narko: Your report concerning whois data inaccuracy regarding the domain spamhaus.org has been confirmed. You will receive an email with further details shortly. Thank you.
[18.03.2013 16:29:26] narko: Any future correspondence sent to ICANN must contain your report ID number.
Please allow 45 days for ICANN’s WDPRS processing of your Whois inaccuracy
claim. This 45 day WDPRS processing cycle includes forwarding the complaint
to the registrar for handling, time for registrar action and follow-up by
ICANN if necessary.

====================================================================

Sven Kamphuis then posts to Pastebin about “OPERATION STOPHAUS,” a tirade that includes a lengthy list of demands Sven says Spamhaus will have to meet in order for the DDoS attack to be called off. Meanwhile, another spam-friendly hosting provider — helpfully known as “Spamahost[dot].com,” joins the chat channel. At this point, the attack has kept Spamhaus.org offline for the better part of 48 hours.

Narko’s account on Stophaus.
[19.03.2013 00:02:43] Yuri: another one hoster, spamahost.com added.
[19.03.2013 00:02:48] Yuri: i hope he can help with some servers.
[19.03.2013 00:02:57] spamahost: Will do ^^
[19.03.2013 00:05:49] eDataKing: be safe when accessing this link, but there was an edu writeup:http://isc.sans.edu/diary/Spamhaus+DDOS/15427
[19.03.2013 00:05:51] spamahost: Spamhaus can blow me.
[19.03.2013 00:06:00] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: me too
[19.03.2013 00:06:20] spamahost: What software you using to send out attacks?
[19.03.2013 00:06:22] spamahost: IRC and bots?
[19.03.2013 00:06:28] Yuri: spamhaus like spamahost very very much.
[19.03.2013 00:06:35] Yuri: that’s the realy true love
[19.03.2013 00:06:37] spamahost: Yes they love us
[19.03.2013 00:38:20] Yuri: MEGALOL
[19.03.2013 00:38:27] Yuri: spamhaus is down 3 days
[19.03.2013 00:38:58] Yuri: this is the graph of our mail server http://mx1.2×4.ru/cgi-bin/mailgraph.cgi
that shows amount of spam rejected by our mail server.
last days there are much less SPAm
[19.03.2013 00:39:13] Yuri: http://mail.2×4.ru same graph here.

====================================================================

The Stophaus members discover that Spamhaus is now protected by Cloudflare. This amuses the Stophaus members, who note that Spamhaus has frequently listed large swaths of Cloudflare Internet addresses as sources of spam.



[19.03.2013 00:47:07] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: cloudflare
[19.03.2013 00:47:48] Antitheist: fuck who would believe
[19.03.2013 00:48:10] Antitheist: after they listed all cloudlares /24 for being criminal supportive because of free reverse proxying
[19.03.2013 00:49:11] Antitheist: here we go again…
[19.03.2013 00:49:12] Antitheist: http://www.spamhaus.org/sbl/query/SBL179312
[19.03.2013 00:49:14] Antitheist: lol
[19.03.2013 00:49:46] Antitheist: it had been officialy bought…b-o-u-g-h-t
[19.03.2013 00:50:45] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: hmm
[19.03.2013 00:50:57] Antitheist: narko?
[19.03.2013 00:51:11] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: k… just take down the spamhaus.org nameservers…all 8 of em
[19.03.2013 00:51:22] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: after all the client on cloudflare is ‘spamhaus.eu’
[19.03.2013 00:51:33] Cali: spamhaus under cloudflare?
[19.03.2013 00:51:35] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: they still need the spamhaus.org nameservers for that and their shitlist to work
[19.03.2013 00:51:40] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: yeah with spamhaus.eu
[19.03.2013 00:51:46] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: which is a cname to spamhaus.org
[19.03.2013 00:51:59] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: so just take out the 8 spamhaus nameservers and stop targetting the old website
[19.03.2013 00:52:09] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: that ALSO takes out their dns shitlists…
[19.03.2013 00:52:12] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: indirectly
[19.03.2013 00:52:22] Yuri: that’s a fuck. a lot of work for us
[19.03.2013 00:53:20] Yuri: may be just let’s make cloudflare down ?
[19.03.2013 00:53:29] Antitheist: thats hard yuri
[19.03.2013 00:53:31] Yuri: so they will refuse any spamhaus
[19.03.2013 00:53:43] Antitheist: you need to cripple level3 and nlayer
[19.03.2013 00:54:04] Antitheist: |OR|
[19.03.2013 00:54:12] Antitheist: you need to spend too much traffic
[19.03.2013 00:54:16] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: narko: new target… the 8 nameservers of spamhaus.org… and still smtp-ext-layer.spamhaus.org ofcourse
[19.03.2013 00:54:20] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: no morewww.spamhaus.org
[19.03.2013 00:54:24] Antitheist: since cloudflares packages are traffic volume priced
[19.03.2013 00:55:44] Karlin Konig: I don’t think they are charging spamhaus
[19.03.2013 00:56:27] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: as stated before, unfair competition, in many ways
[19.03.2013 00:56:28] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lulz
[19.03.2013 00:57:46] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: hmm is cloudflare hosting? or a reverse proxy?
[19.03.2013 00:57:57] Cali: reverse proxy.
[19.03.2013 00:58:00] Yuri: reverse
[19.03.2013 00:58:09] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: as when its a reverse proxy, it probably goes to that spamhaus.as1101.net box
[19.03.2013 00:58:13] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: aka, surfnet.
[19.03.2013 01:00:10] Cali: already offline
[19.03.2013 01:00:17] Cali: This website is offline
[19.03.2013 01:02:26] narko: I will make down their cloudflare if I have enough free servers
[19.03.2013 01:02:30] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: they moved it to cloudlfare
[19.03.2013 01:02:31] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[19.03.2013 01:02:43] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: then just go for the nameservers on spamhaus.org
[19.03.2013 01:02:49] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: which also breaks their dns shitlist
[19.03.2013 01:02:52] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: after 24h
[19.03.2013 01:02:55] Cali: usually websites use cloudflare dns as well.
[19.03.2013 01:02:58] Cali: so they might change soon.
[19.03.2013 01:03:03] Cali: I think you should give them some hope
[19.03.2013 01:03:10] Cali: because they will be so proud to bring it back
[19.03.2013 01:03:14] Cali: then you switch it off again
[19.03.2013 01:03:20] Cali: they will rage
[19.03.2013 01:03:23] Karlin Konig: it’s down again
[19.03.2013 01:03:24] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: they do… spamhaus.EU is on cloudflare dns
[19.03.2013 01:03:25] Karlin Konig: lol
[19.03.2013 01:03:30] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP:spamhaus.org… is on spamhaus dns
[19.03.2013 01:03:45] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: for the very obvious reason that they have 70 dns shitlist servers in that zone
[19.03.2013 01:03:49] Cali: yeah but I think they might change that soon.
[19.03.2013 01:03:52] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: and those use their weird rotating system
[19.03.2013 01:03:54] Cali: ahah
[19.03.2013 01:03:57] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: cloudflare can’t do that
[19.03.2013 01:04:04] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: they can’t change the domain of the dns shitlist
[19.03.2013 01:04:05] Cali: even with the paid version?
[19.03.2013 01:04:07] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: so they have to keep that
[19.03.2013 01:04:30] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: soo… if they come up again, just kill the dns servers on their main domainspamhaus.org
[19.03.2013 01:04:33] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP:
[19.03.2013 01:04:33] Cali: ok, now it is online and responds.
[19.03.2013 01:04:50] narko: ok
[19.03.2013 01:04:52] narko: moment
[19.03.2013 01:05:07] Cali:http://www.spamhaus.org/images/spamhaus_dnsbl_basic.gif “meet spamhaus policy”
[19.03.2013 01:05:07] Cali: lol
[19.03.2013 01:05:14] Cali: like IPs have to meet Spamhaus policies
[19.03.2013 01:05:18] Cali: lol
[19.03.2013 01:05:24] narko: they are using the cloudflare paid plan
[19.03.2013 01:05:31] narko: as they have 5 IP
[19.03.2013 01:05:31] narko: not 2
[19.03.2013 01:05:44] narko: i think it means that cf will keep them longer
[19.03.2013 01:05:46] narko:
[19.03.2013 02:09:03] narko: added some extra gbit/s to two dns servers that seemed half-up lets see if google dns renews it now
[19.03.2013 02:09:28] Yuri: fuck.. no dns resolve :))))
[19.03.2013 02:09:45] narko: (mm)
[19.03.2013 02:09:57] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: when -these- time out, they’re out of business
[19.03.2013 02:10:01] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: <<>> DiG 9.8.1-P1 <<>> A b.ns.spamhaus.org
[19.03.2013 08:01:24] Yuri: good morning
[19.03.2013 08:01:32] Yuri: it was short night for me…. fuck
[19.03.2013 08:01:40] Yuri: spamhaus is down ? again ?
[19.03.2013 08:02:09] Yuri: looks it’s some our friend work
[19.03.2013 08:10:30] simomchen: how about we hijack spamhaus’s IP together , if can not take them down again ?
[19.03.2013 08:10:59] Yuri: we would like to.
[19.03.2013 08:11:08] Yuri: but we need upstream who will allow us to do that
[19.03.2013 08:11:25] simomchen: we can just announce those over IX exchange
[19.03.2013 08:11:34] simomchen: them , do not need upstream allow this
[19.03.2013 08:11:39] nmetluk: Russian upstreams allow:)
[19.03.2013 08:13:10] Yuri: (at least we have one good russian upstream here)
[19.03.2013 08:14:15] Yuri: spamhaus desided to bring some shit sbls toinfiumhost.com, /22 listed just for nothing.and some extra SBLs to pinspb
[19.03.2013 08:14:28] eDataKing: that is how they do it
[19.03.2013 08:14:35] eDataKing: that is why it is terrorism
[19.03.2013 08:14:57] simomchen: SH will force upstreams disconnect them
[19.03.2013 08:15:05] simomchen: that’s their next step
[19.03.2013 08:15:15] Yuri: they are too big to be disconneted
[19.03.2013 08:15:22] eDataKing: yes, the upstream does not really make the decision because the decision is coerced through damages
[19.03.2013 08:15:43] eDataKing: who is too big to be disconnected?
[19.03.2013 08:16:03] simomchen: infiumhost.com ?
[19.03.2013 08:16:31] Yuri: pinspb.ru
[19.03.2013 08:16:33] Yuri: gpt.ru
[19.03.2013 08:16:42] Yuri: and other that was with some new sbls today
[19.03.2013 08:16:50] Yuri: currenty it’s just nothing serious
[19.03.2013 08:16:58] Yuri: they keep searching
[19.03.2013 08:24:33] simomchen: Donate to the fund needed to shut SH down for good. Send your donations via Bitcoin to 17SgMS56W6s1oMU7oEZ66NFkbEk1socnTJ

====================================================================

At this point, several media outlets begin erroneously reporting that the DDoS attack on Spamhaus and Cloudflare is the work of Anonymous (probably because Kamphuis ended his manifesto with the Anonymous tagline, “We do not forgive. We do not forget”).

[19.03.2013 12:35:51] Antitheist: lol, anonymous indonesia took the responsibility for the spamhaus ddos
[19.03.2013 12:35:51] Antitheist: https://twitter.com/anonnewsindo
[19.03.2013 12:36:38] Antitheist: wait no, its all over softpedia! hahaha
[19.03.2013 12:37:31] Antitheist: http://news.softpedia.com/news/Anonymous-Hackers-Launch-DDOS-Attack-Against-Spamhaus-338382.shtml
[19.03.2013 12:46:11] narko: http://www.spamhaus.org/sbl/query/SBL179322
[19.03.2013 12:46:39] Antitheist: http://www.spamhaus.org/sbl/query/SBL179321
[19.03.2013 12:55:30] Yuri: people report that MAIL from spamhaus start working
[19.03.2013 12:55:42] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: oeh! spam!
[19.03.2013 12:56:03] Antitheist: the mail is their weakest point, since cloudflare cannot protect it
[19.03.2013 12:56:22] Antitheist: so we need to hit there. the result means no SBL removals
[19.03.2013 12:56:33] Antitheist: mad mad admins pulling off hair
[19.03.2013 14:46:09] Yuri: news.softpedia.com
[19.03.2013 14:46:16] Antitheist: they think its anonymous because of Svens pastebin
[19.03.2013 14:46:48] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: also good
[19.03.2013 14:46:56] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: then the rest of anon also thinks its anon
[19.03.2013 14:47:00] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: and starts to help
[19.03.2013 14:47:01] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[19.03.2013 14:47:17] Yuri: wow what a news
[19.03.2013 14:47:17] Antitheist: lol anon-amplification yeah
[19.03.2013 14:47:26] Yuri: spamhaus says in twitter that softpedia new is false
[19.03.2013 14:47:29] Yuri: :)))
[19.03.2013 14:47:40] Yuri:http://www.spamhaus.org/news/article/693/softpedia-publish-misleading-story-of-anonymous-attack-on-spamhaus
[19.03.2013 15:10:05] eDataKing: 1. Let them think Anons were behind it and do not dispute
[19.03.2013 15:10:05] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: can’t sign up for twitter as i don’t have any working email lol
[19.03.2013 15:10:21] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: edataking: its allready all over the press that its not anons lol.
[19.03.2013 15:10:22] Antitheist: I know Mohit from thehackernews, if it gets posted there it will soon be viral
[19.03.2013 15:10:26] eDataKing: or 2. Remind them that Anons are everyone and Anonymous as a group did not orchestrate it
[19.03.2013 15:10:30] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: at least in .nl its quite clear that its the republic cyberbunker and others
[19.03.2013 15:10:30] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: haha
[19.03.2013 15:10:58] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: that anon also has some ehm… stuff to ‘arrange’ with spamhaus, is a different story
[19.03.2013 15:11:19] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: *points out that over half of my facebook friends have the masks anyway*
[19.03.2013 15:11:28] eDataKing: Anonymous name gets major media
[19.03.2013 15:11:33] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: and that i’m still officially the PR guy for anonymous germany
[19.03.2013 15:14:36] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: y my name don’t fit twitter..
[19.03.2013 15:14:40] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: HRH Sven Olaf Prince
getting twitter accounts shut down, listing stophaus on the sbl.

====================================================================

Spamhaus has by now worked out the identity of many Stophaus members, and has begun retaliating at them individually by listing Internet addresses tied to their businesses and personal life. Here, Narko reveals that he runs his own (unprofitable) hosting firm that Spamhaus found and listed it as an address to be blocked because it was hosting stophaus[dot]org.

[19.03.2013 17:50:04] narko: im back
[19.03.2013 17:50:25] narko: the nameservers for stophaus need to be changed
[19.03.2013 17:51:04] narko: spamhaus SBLed my site and my host will terminate me unless spamhaus tells them that it’s ok
[19.03.2013 17:51:08] narko: fucking internet police
[19.03.2013 17:52:57] eDataKing: ok, what are we changing them to?
[19.03.2013 17:53:40] narko: i will set up dns servers on my home connection
[19.03.2013 17:53:41] narko: lol
[19.03.2013 17:53:45] narko: i dont think my isp gives a shit
[19.03.2013 17:53:48] narko: i’m alraedy in PBL
[19.03.2013 17:53:56] eDataKing: lol, as long as you are safe
[19.03.2013 17:53:59] narko: what does it matter if i’m in SBL?
[19.03.2013 17:54:04] narko: well.. as long as they won’t ddos me
[19.03.2013 17:54:05] eDataKing: ok, then it should be all good
[19.03.2013 17:54:06] narko: I have a static ip
[19.03.2013 17:54:18] eDataKing: what about your upstream?
[19.03.2013 17:54:50] narko: I want to buy a /24 and host this just to fuck spamhaus
[19.03.2013 17:54:57] narko: anyone selling /24 i pay €200
[19.03.2013 17:55:34] narko: i cannot believe that my host is telling me i need to leave for a fake SBL listing that is not even hosted at their network
[19.03.2013 17:55:38] Yuri: they will list all network at once and put upsteam
[19.03.2013 17:55:39] narko: why do they listen to spamhaus..?
[19.03.2013 18:21:28] simomchen: let me make a CC to them in China
[19.03.2013 18:21:35] eDataKing: then this will kill them in the end
[19.03.2013 18:21:49] Antitheist: https://www.cloudflare.com/business
[19.03.2013 18:22:10] Yuri: stophaus.com moved to new DNS.
[19.03.2013 18:22:16] simomchen: I brought 50K adsl Broilers just now
[19.03.2013 18:22:48] eDataKing: Then their DNS is a ticking timebomb dependent on public support. They don’t have a lot of that left
[19.03.2013 18:23:46] Yuri: 50k of what?
[19.03.2013 18:23:52] Antitheist: DNS of stophaus should be hosted on cloudflare imho
[19.03.2013 18:24:13] Antitheist: they will be afraid to list it lol
[19.03.2013 18:24:20] simomchen: 50000 ADSL broilers zombies , hehe
[19.03.2013 18:24:23] Yuri: cloudflare will kick off
[19.03.2013 18:24:27] Yuri: oohh.. shit.
[19.03.2013 18:24:48] Yuri: we need a plan how to fight
[19.03.2013 18:27:02] simomchen: Antitheist:
<<< we need bots that will do large POST requests on the search form of ROKSOyes, that’s CC attack I said just now. ROKSO is not big enought , I’m CC their http://www.spamhaus.org/sbl/latest/ currently
[19.03.2013 18:27:11] simomchen: do not know cloudflare can handle that
[19.03.2013 18:27:24] Antitheist: SBL are not in mysql
[19.03.2013 18:27:53] Antitheist: there is no search on the DB when you request them [19.03.2013 18:28:06] eDataKing: true
[19.03.2013 18:28:12] Antitheist: but a search form, any of them, must have at least 1 SELECT statement [19.03.2013 18:28:15]
simomchen: okay, http://www.spamhaus.org/rokso/ how about this page ?
[19.03.2013 18:28:23] Antitheist: yes, see the search form
[19.03.2013 18:28:27] eDataKing: RBLs are on a Logistics server at abuseat.org
[19.03.2013 18:28:29] Antitheist: you need to post long random shit there
[19.03.2013 18:28:34] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: SBL157600 5.157.0.0/22 webexxpurts.com 19-Mar 13:53 GMT Spammer hosting (escalation) SBL157599 5.153.238.0/24 webexxpurts.com 19-Mar 13:53 GMT Spammer hosting (escalation)
[19.03.2013 18:28:36] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[19.03.2013 18:28:41] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: wasn’t he in here the other day
[19.03.2013 18:28:46] eDataKing: at least the cbl is
[19.03.2013 18:28:54] eDataKing: yes
[19.03.2013 18:28:59] eDataKing: He left?
[19.03.2013 18:29:05] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: dunno
[19.03.2013 18:29:05] simomchen: okay, let me make a ‘search’
[19.03.2013 18:29:08] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: changed names?
[19.03.2013 18:29:12] eDataKing: maybe
[19.03.2013 18:29:21] eDataKing: that was who I thought Darwin was
[19.03.2013 18:29:47] eDataKing: like he changed his name in the middle of a conversation
[19.03.2013 18:29:54] eDataKing: and Darwin picked up the chat
[19.03.2013 18:29:54] Antitheist: oh good news, its available in GET as well
[19.03.2013 18:30:01] Antitheist: http://www.spamhaus.org/rokso/search/?evidence=LONGSHITGOESHERE
[19.03.2013 18:30:40] eDataKing: They are desperate to take down the content though
[19.03.2013 18:30:55] eDataKing: I knew they would be scared to show their faces to public scrutiny
[19.03.2013 18:36:03] Yuri: SBL179370 66.192.253.42/32 twtelecom.net 19-Mar 15:15 GMT Suavemente/SplitInfinity/Innova Direct
: Feed to Jelly Digital (AS4323 >>> AS33431)
SBL179369 4.53.122.98/32 level3.net
19-Mar 15:03 GMT Suavemente/SplitInfinity/Innova Direct : Feed to Critical Data Network, Inc. (AS3356 >>> AS53318) spamhaus started to fuck hardly everywhere. they are angry.
[19.03.2013 18:37:39] Antitheist: no mercy anymore, everyone who they scraped out of stophaus members gets the entire /24 listed in ROKSO
[19.03.2013 18:37:40] simomchen: cloudflare service them , we are angry too
[19.03.2013 18:40:35] simomchen: but if the ddos keeping , I think spamhaus would go bankrupt
[19.03.2013 18:40:52] narko: they won’t go bankrupt
[19.03.2013 18:40:55] narko: he will just buy a smaller boat
[19.03.2013 18:41:00] simomchen: because cloudflare must charge tons of money form them
[19.03.2013 18:41:34] simomchen: what they can do in that boat ? if they do not pay to cloudflare , they will down again
[19.03.2013 18:41:48] narko: cloudflare only cost $200 per month
[19.03.2013 19:02:27] Yuri: For SBLs spamhaus
use
[19.03.2013 19:02:27] Yuri:
<<< http://stopforumspam.com/
https://www.projecthoneypot.org/ – этот точно
https://zeustracker.abuse.ch/
https://spyeyetracker.abuse.ch/those sites 100%
[19.03.2013 19:02:39] narko: ok let’s make these down
[19.03.2013 21:32:06] narko: i run my host company since FEB 2012 and i am still losing like 350$ per month lol
[19.03.2013 21:32:28] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: we’ve been doing it commercially since 1996 on ‘cb3rob’
[19.03.2013 21:32:34] eDataKing: how much would that be?
[19.03.2013 21:32:39] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: and well.. there are times where it runs at a loss
[19.03.2013 21:32:45] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: and there are times where it makes heaps
[19.03.2013 21:32:55] narko: i have not had a single month
[19.03.2013 21:33:01] narko: where the costs of servers+licenses were covered..
[19.03.2013 21:33:12] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: you don’t have your own servers either/
[19.03.2013 21:33:13] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: ?
[19.03.2013 21:33:16] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: just reselling?
[19.03.2013 21:33:32] narko: rent server, install cpanel, advertise
[19.03.2013 21:33:33] narko: (y)
[19.03.2013 21:33:45] eDataKing: agreed
[19.03.2013 21:33:54] narko: but I think soon i will buy my own servers and colo
[19.03.2013 21:33:56] narko: it will be cheaper
[19.03.2013 21:34:04] eDataKing: agreed as well
[19.03.2013 21:34:06] narko: the problem is
[19.03.2013 21:34:11] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: i’d say thats the only way to do it
[19.03.2013 23:43:05] narko: i don’t understand this
[19.03.2013 23:43:16] narko: how can cloudflare take 100gbps of udp and latency is not even increased by 1ms
[19.03.2013 23:47:05] Antitheist:http://www.apricot2013.net/__data/assets/pdf_file/0009/58878/tom-paseka_1361839564.pdf
[19.03.2013 23:47:19] Antitheist: CloudFlare has seen DNS reflection attacks hit 100Gbit traffic globally
[19.03.2013 23:47:23] Antitheist: they are used to it
[19.03.2013 23:47:49] narko: when they were hosting at rethem hosting
[19.03.2013 23:47:52] narko: I took down sprint
[19.03.2013 23:47:54] narko: i took down level3
[19.03.2013 23:47:56] narko: i took down cogent
[19.03.2013 23:48:06] narko: but cloudflare nothing!
[19.03.2013 23:48:26] narko: back in 2009 cloudflare went down with 10gbps
[19.03.2013 23:48:28] narko: all down..
[19.03.2013 23:49:34] narko: o i’m causing some dropped packets now
[19.03.2013 23:56:06] Cali: narko, was it you who DDoSed us like a year and half ago ?
[19.03.2013 23:56:14] narko: what network?
[19.03.2013 23:56:27] narko: or site
[19.03.2013 23:56:32] narko: sent it me in private chat and i can tell you
[20.03.2013 00:05:39] narko: http://i.imgur.com/M2mbNE0.png
[20.03.2013 00:05:44] narko: Spamhaus cloudflare current status
[20.03.2013 00:05:48] narko: with over 100Gbps of attack traffic
[20.03.2013 00:07:39] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: hmm does this affect other cloudflare customers, as in that case its bye bye spamhaus pretty soon
[20.03.2013 00:07:40] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[20.03.2013 00:07:49] narko: i dont know
[20.03.2013 00:07:56] narko: i hope so because i cant keep such traffic up for a long time
[20.03.2013 00:08:02] narko: it’s probably closer to 200 than 100 Gbps
[20.03.2013 00:08:07] Cali: it will be harder than that I think.
[20.03.2013 00:09:35] Cali: no more icmp @cloudflare?
[20.03.2013 00:09:52] narko: 7 * * * Request timed out.

[20.03.2013 00:22:24] Antitheist: they list every IP/DNS that resolves stophaus in any way
[20.03.2013 00:22:31] narko: “Please update us when this client no longer utilises *any* part of our network so we can get back in touch with Spamhaus.”
[20.03.2013 00:22:35] Antitheist: we can change it every hour and block the entire internet lol
[20.03.2013 00:22:47] narko: They do not understand the word “THIS CLIENT HAS NOTHING TO DO WITH YOUR NETWORK”
[20.03.2013 00:22:53] narko: they treat it like it’s a request from law enforcement
[20.03.2013 00:22:56] narko: not some moron on a boat
[20.03.2013 00:47:00] Antitheist: so whats up with wordtothewise
[20.03.2013 00:47:02] narko: i only met you peoples on friday and never heard of most of you before then
[20.03.2013 00:47:29] eDataKing: lol, I just talk like I know everyone
[20.03.2013 00:47:48] eDataKing: It’s better than being secretive. I get nervous around quite people.
[20.03.2013 00:47:59] eDataKing: I think they are plotting on me lol
[20.03.2013 00:48:01] narko: I said too much already in this chat
[20.03.2013 00:48:04] narko: I’m expecting the raid soon
[20.03.2013 00:48:06] narko:

====================================================================

Narko has directed most of his botnet resources at Cloudflare now instead of Spamhaus, and the group is surprised to see Spamhaus go offline when it was hidden behind Cloudflare’s massive DDoS protection resources. Also, Yuri enlists the help of some other attackers to join in the assault.

[20.03.2013 01:00:32] Antitheist: This website is offline. No cached version is available
[20.03.2013 01:00:33] Antitheist: LOL
[20.03.2013 01:00:47] narko: lol
[20.03.2013 01:00:50] narko: not working for me either
[20.03.2013 01:00:56] Antitheist: narko you are the king
[20.03.2013 01:00:59] Antitheist: haha
[20.03.2013 01:01:00] narko: i didnt do anything
[20.03.2013 01:01:03] narko: i was just attacking cloudflare
[20.03.2013 01:01:16] Antitheist: well, thats not something they wanted to have
[20.03.2013 01:01:17] narko: see now its back up
[20.03.2013 01:01:36] Cali: It is offline here.
[20.03.2013 01:01:44] Antitheist: off…
[20.03.2013 01:01:45] narko: it went down again
[20.03.2013 01:01:51] narko: and back
[20.03.2013 01:03:11] Cali: yup
[20.03.2013 01:04:33] narko: let’s create some more records
[20.03.2013 01:04:36] narko: for DNS of stophaus
[20.03.2013 01:04:47] narko: dummy records, such as the IP of softlayer.com , etc
[20.03.2013 01:04:55] narko: it won’t affect the site because it will just try from the next server
[20.03.2013 01:05:01] narko: but they’re going to SBL some big sites
[20.03.2013 01:05:02] narko: lol
[20.03.2013 01:05:47] Antitheist: it will create more damage if we list MTAs
[20.03.2013 01:06:06] narko: ok let’s see
[20.03.2013 01:06:20] narko:
[20.03.2013 02:16:57] narko: Cloudflare changed the ips
[20.03.2013 02:16:59] narko: put only 2 IPs now
[20.03.2013 02:17:05] narko: will move attack to these IPs
[20.03.2013 02:18:24] narko: also I have a friend with a small botnet. I asked him to contribute
[20.03.2013 02:19:45] Yuri: i see.
[20.03.2013 02:19:59] Yuri: i asked some hackers to assist also
[20.03.2013 02:20:31] narko: my friend is in saudi arabia. he has bots in arab regions. will provide some diversity to the attack.
[20.03.2013 02:20:52] Yuri: spamhaus sbl site is the high end of iceberg
[20.03.2013 02:21:11] Yuri: did you try to put down spamhas relates sites?
[20.03.2013 02:21:23] narko: after spamhaus.org main site :))
[20.03.2013 02:21:55] narko: i am just getting very annoyed at this company now
[20.03.2013 02:22:08] narko: i just received 2 minutes ago “We are sorry to inform that your account has been terminated.” from my host.
[20.03.2013 02:22:14] narko: due to SBL
[20.03.2013 02:22:43] Yuri: on what host?
[20.03.2013 02:22:52] narko: EuroVPS.com
[20.03.2013 02:23:02] Yuri: write me pm what do you need
[20.03.2013 03:13:26] narko: lets host here
[20.03.2013 03:13:38] narko:http://www.beltelecom.by/business/hosting/virtual-dedicated-server
[20.03.2013 03:13:45] narko: i dont think they can even speak english. to read the abuse report from spamhaus.
[20.03.2013 03:14:03] Cali: lol
20.03.2013 17:07:45] eDataKing: lol
[20.03.2013 17:27:58] narko: looks like one of the cloudflare dc is down
[20.03.2013 17:28:08] narko: previously my connection to spamhaus was to amsterdam
[20.03.2013 17:28:10] narko: now it’s to paris
[20.03.2013 17:28:53] simomchen: keeping ddos them , then , cloudflare will cick SH out
[20.03.2013 17:29:03] narko: i am adding more
[20.03.2013 17:29:20] narko: if you know anyone with botnet – ask them to help too. there will be a point where even the $2000 cloudflare enterprise plan is not worth it to them.
[20.03.2013 17:31:42] simomchen: maybe someone joined us. SH released xxx is making ddos them. and some other guys saw this.but do not connect us. they was blackmailed by SH before. so , it’s a hidden retaliation time for them
[20.03.2013 17:32:04] narko: hope so
[20.03.2013 17:32:09] narko: it seems they split the load between 2 dc [datacenters] actually
[20.03.2013 17:32:12] Antitheist: who is ddosing them?
[20.03.2013 17:32:17] narko: spamhauas has 2 ip and 1 is amsterdam other is paris
[20.03.2013 17:32:18] Antitheist: where did you see it idear4business
[20.03.2013 17:33:16] Yuri: look, there too much people who is not active here. may be we could remove them from this chat ?
[20.03.2013 17:33:29] narko: yes I think that’s good idea. there’s some people who i have never seen one messaage
[20.03.2013 17:33:48] simomchen: they do not wanna to show their identity, just wanna to make retaliation. I guess those. can not seeing this. but at least , some of our clients also joined , and making ddos SH from China. they hate spamhaus , because SH made their domains ‘clent hold’ (over 50000 domains) in the passed year
[20.03.2013 17:33:49] Yuri: let’s create new one subchat and move there. how is the idea?
[20.03.2013 17:34:32] Antitheist: spamhaus made 500 of my domains hold
[20.03.2013 17:34:38] narko: everyone who has bp host
[20.03.2013 17:34:40] Antitheist: cnobin, its a bizcn reseller
[20.03.2013 17:34:46] narko: hijack the botnets of your clients and ddos spamhaus
[20.03.2013 17:34:51] Antitheist: lol)))
[20.03.2013 17:35:14] narko: my experience with BP hosts – you can always get some free bots from whoever used the IP previously :))))
[20.03.2013 17:35:27] Antitheist: if you have the same panel
[20.03.2013 17:35:40] narko: well I just adapt my software to accept their commands
[20.03.2013 17:35:41] simomchen: no need to hijack , if our clients wanna to ddos someone , they will buy some botnets. it’s cheap in China , like 0.01 EUR/each
[20.03.2013 17:35:44] narko: most of them are not encrypted at all
[20.03.2013 17:35:45] NM:
[20.03.2013 17:35:50] simomchen: Sven also know that
[20.03.2013 17:35:56] narko: each bot?
[20.03.2013 17:36:01] simomchen: yes
[20.03.2013 17:36:06] simomchen: ADSL bot
[20.03.2013 17:36:10] narko: what is the upload speed of china ADSL?
[20.03.2013 17:36:16] simomchen: with dynamic IP
[20.03.2013 17:36:24] simomchen: just 50-100Kbps
[20.03.2013 17:36:40] narko: we need some netherland/sweden/romania bots
[20.03.2013 17:36:49] narko: they have 100mbps or more
[20.03.2013 17:37:04] NM: In Russia too
[20.03.2013 17:37:33] simomchen: SH is not works in China till now. and sometime , they are going up down up down.
[20.03.2013 17:38:09] narko: spamhaus can make down .cn domains ?
[20.03.2013 17:38:18] Yuri: yes.
[20.03.2013 17:38:39] simomchen: our clients is selling something to EU and US, so , they do not use .cn
[20.03.2013 17:38:50] simomchen: usually , they use .com/net
[20.03.2013 17:39:16] narko: they should apply for a new tld
[20.03.2013 17:39:17] narko: .ugg
[20.03.2013 17:39:33] simomchen: yes
[20.03.2013 17:39:51] Antitheist: .rx
[20.03.2013 17:39:54] Yuri: )))))
[20.03.2013 17:40:09] Yuri: .ugg (y)
[20.03.2013 17:40:17] narko: (sun)
[20.03.2013 17:40:43] narko: i hosted botnets under .w2c.ru domain
[20.03.2013 17:41:10] narko: and the domain was not made down
[20.03.2013 17:41:34] Yuri: hey. wtf, it’s my domain
[20.03.2013 17:41:41] narko: yes I had dedicated server
[20.03.2013 17:41:44] narko: free subdomain
[20.03.2013 17:41:57] Yuri: :O:D
[20.03.2013 17:42:11] narko: but i needed to move
[20.03.2013 17:42:19] narko: because a big ISP in Europe blocked all your ip range
[20.03.2013 17:42:26] narko: i lost half my bots
[20.03.2013 17:44:53] narko: ok. currently i have running against spamhaus:
[20.03.2013 17:45:15] narko: ~100Gbps UDP
~ 20M pps TCP
~ 65k req/s HTTP
distributed between the 2 IP
[20.03.2013 17:45:21] narko: cloudflare must remove them soon..
[20.03.2013 17:45:21] narko: cloudflare must remove them soon.
[20.03.2013 19:25:20] narko: i think spamhaus wrote to my pamyent processor
[20.03.2013 19:25:23] narko: has it happened before?
[20.03.2013 19:25:44] narko: an IP address started to browse my site. assigned to 2Checkout Inc. now my merchant account is put into a review status.
[20.03.2013 19:27:32] eDataKing: How did they get your processor’s info?
[20.03.2013 19:27:43] narko: they require it to be written in the site
[20.03.2013 19:27:48] narko: “Services provided by 2Checkout Inc”
[20.03.2013 19:27:51] eDataKing: Also, they tried that with my Paypal account for 3 years. We are still Top-Tier members
[20.03.2013 19:28:03] eDataKing: they reviewed the records and it took 6 hours to be restored
[20.03.2013 19:28:18] eDataKing: no other complaint ever made it past the first level of abuse
[20.03.2013 19:28:20] narko: lol
[20.03.2013 19:28:31] narko: someone called paypal and said i was threatening to kill them unless they paid me money
[20.03.2013 19:28:34] narko: and my account was limited for a week

====================================================================

At this point, Narko is sending between 150-300 Gbps of packet love at Cloudflare’s major datacenter Internet addresses. Cloudflare.com briefly goes offline. Cloudflare publishes a blog post stating that the attack was successfully handled and mitigated by Cloudflare. Narko disagrees, saying Cloudflare was able to mitigate the attack because he paused it. Spamhaus posts an update on the ongoing attacks, claiming that most of its operations are returning to normal.

Narko shares this screenshot in the chat forum. It shows that the attack on Cloudflare is at more than 100 Gbps, which is more than enough to knock most sites offline.
20.03.2013 19:58:21] narko: did someone else start attack to cloudflare? their site is even down now :))
[20.03.2013 19:58:27] Yuri: we need to post it to the public, in twitter and etc?
[20.03.2013 20:33:19] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: we’ll just break the god damn internet if thats what it takes
[20.03.2013 20:33:20] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[20.03.2013 20:46:19] eDataKing: http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho
[20.03.2013 20:46:38] eDataKing: The DDoS That Knocked Spamhaus Offline (And How We Mitigated It)
[20.03.2013 20:46:43] eDataKing: they mitigated it?
[20.03.2013 20:46:45] eDataKing: news to me
[20.03.2013 20:47:11] eDataKing: hmm
[20.03.2013 20:47:12] eDataKing: CloudFlare’s own history grew out of Project Honey Pot, which started as an automated service to track the resources used by spammers and publishes the HTTP:BL.
[20.03.2013 20:47:21] eDataKing: good data
[20.03.2013 20:47:24] eDataKing: didn’t know that
[20.03.2013 20:48:53] eDataKing: Beginning on March 18th?
[20.03.2013 20:48:59] eDataKing: that is factually incorrect
[20.03.2013 20:51:11] narko: reading now
[20.03.2013 20:51:47] eDataKing: the attack did not start a day before their great admins mitigated it
[20.03.2013 20:51:54] eDataKing: is it even mitigated?
[20.03.2013 20:52:12] narko: hehehehe :)))))))))))))))))))))
[20.03.2013 20:52:15] narko: this is like 140Gbps
[20.03.2013 20:52:27] eDataKing: lol
[20.03.2013 20:52:37] eDataKing: don’t look like mitigation to me lol
[20.03.2013 20:52:57] eDataKing: Their article almost reads as a challenge
[20.03.2013 20:53:14] narko: I stopped the attack
[20.03.2013 20:53:25] narko: i am generating a new dns list. then I will start again and it will be over 200 gbps
[20.03.2013 20:53:30] narko: the current list is quite old

====================================================================

Narko grows concerned about getting busted because Andrew (eDataKing) mistakenly published on the anti-spam Google Group forum NANAE a screenshot that included Narko’s Skype screen name. Helpfully for the U.K. authorities closing in on him, Narko provides a link to view the screenshot that includes what he identifies as his Skype screen name.

Narko’s screen as he’s in the middle of launching attacks on Spamhaus. A portion of his Skype address at the time can be seen in the upper right corner of the screenshot.
20.03.2013 21:08:59] eDataKing: lol,
[20.03.2013 21:08:59] eDataKing: This morning at 09:47 UTC CloudFlare effectively dropped off the Internet. The outage affected all of CloudFlare’s services including DNS and any services that rely on our web proxy. During the outage, anyone accessing CloudFlare.com or any site on CloudFlare’s network would have received a DNS error. Pings and Traceroutes to CloudFlare’s network resulted in a “No Route to Host” error.
[20.03.2013 21:09:15] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP:
[20.03.2013 21:09:25] eDataKing: sry, that was on 03-03
[20.03.2013 21:09:27] eDataKing: not related
[20.03.2013 21:09:38] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: someone was doing it better than narko ?
[20.03.2013 21:09:40] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: wth
[20.03.2013 21:09:41] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[20.03.2013 21:09:48] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: get that guy in here too haha
[20.03.2013 21:09:57] eDataKing: wait to see what narko does next though
[20.03.2013 21:15:03] Yuri: spamhaus down ?
[20.03.2013 21:15:07] Yuri: cloudflare shows down
[20.03.2013 21:15:34] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: nope
[20.03.2013 21:15:38] eDataKing: nope
[20.03.2013 21:19:37] narko: we need to find more people.
[20.03.2013 21:19:49] narko: cloudflare network just has a lag with my attack
[20.03.2013 21:20:00] narko: my attack + some botnets will take them down entirely. then they have no choice but to kick spamhaus.
[20.03.2013 22:24:39] narko: who posted the screenshot on nanae please remove it
[20.03.2013 22:24:41] narko: it has written my skype name
[20.03.2013 22:24:59] narko: t.ravis
[20.03.2013 22:25:04] eDataKing: that was the indian
[20.03.2013 22:25:13] eDataKing: you said to post it
[20.03.2013 22:25:22] eDataKing: I’ll tell him
[20.03.2013 22:25:31] eDataKing: I don’t think it can be removed though
[20.03.2013 22:25:52] eDataKing: argh, why didn’t you edit that image?
[20.03.2013 22:26:01] eDataKing: I will be sure to check all images from here out
[20.03.2013 22:26:11] eDataKing: but doesn’t the image only say probing?
[20.03.2013 22:26:24] narko: no it has my skype username
[20.03.2013 22:26:27] narko: i didn’t expcet it to be posted
[20.03.2013 22:26:29] narko: i just said
[20.03.2013 22:26:31] narko: narko:
<<< http://i.imgur.com/prDIVYU.png — current status
[20.03.2013 22:27:51] Yuri: don’t see any info on screenshot
[20.03.2013 22:28:09] eDataKing: I see all but the last digit
[20.03.2013 22:28:16] eDataKing: enough to run a trace on that skype account
[20.03.2013 22:28:28] eDataKing: but nothing incriminating
[20.03.2013 22:28:48] eDataKing: don’t they already blame you though?
[20.03.2013 22:28:59] narko: no one on nanae/spamhaus knows about me
[20.03.2013 22:29:03] eDataKing: I’ll tell the indian to wait for approval bwefore posting anything else
[20.03.2013 22:29:16] eDataKing: I will also look at the images if there are any more screens
[20.03.2013 22:29:38] eDataKing: can you grab a new skype account and nix this one just in case?
[20.03.2013 22:29:44] narko: i am just worried. because it has my skype name < i am uploaded the image from my home connection, and FBI in USA already has a case on me ddosing before, they were going to people in america and asking them questions about me
[20.03.2013 22:29:44] narko: no
[20.03.2013 22:29:45] narko: its fine for me
[20.03.2013 22:29:48] narko: for now *
[20.03.2013 22:29:50] eDataKing: you said this one was for this session only right?
[20.03.2013 22:29:53] narko: yes
[20.03.2013 22:30:22] eDataKing: the image won’t have any hex code though because it is on imgur
[20.03.2013 22:30:24] Yuri: other solution – is to upload same imase from other IPs
[20.03.2013 22:30:31] eDataKing: yes
[20.03.2013 22:30:36] Yuri: so they have to think who is that was…
[20.03.2013 22:30:41] eDataKing: oh, gotcha
[20.03.2013 22:30:44] eDataKing: yeah
[20.03.2013 22:31:13] eDataKing: I am so used to be completly anon that I would have never imagined you imported that from home
[20.03.2013 22:31:54] eDataKing: can you delete it from imgur?
[20.03.2013 22:32:30] eDataKing: I want to mitigate any issues because the indian is my dude and I feel responsible for what he did
[20.03.2013 22:32:34] narko: no
[20.03.2013 22:32:37] narko: nothing will happen
[20.03.2013 22:32:41] narko: nothing has ever happened
[20.03.2013 22:40:58] narko: but I ran an illegal site (carding, ddos, etc) from 2010-2012 and 90% customers were US
[21.03.2013 03:40:43] narko: well i’m going to sleep
[21.03.2013 03:40:49] narko: wll attack cloudflare again tomorrow

====================================================================

Stophaus claims victory when Spamhaus moves off of Cloudflare’s network and over to Amazon. The Stophaus members begin planning their next move.

[21.03.2013 10:00:21] eDataKing: CBL (cbl,http://t.co/M9Jz8KKvi5) is up again, after a heavy DDOS. It is now protected through amazon cloud. #spamhaus
[21.03.2013 10:14:19] simomchen: so , SH have separated , and protedted by 2 cloud ?
[21.03.2013 10:14:54] eDataKing: yep
[21.03.2013 10:15:10] eDataKing: but they are only buying a short amlunt of time really
[21.03.2013 10:16:23] simomchen: they must have a contract with cloudflare and amazon , once ddos leave over 7 days. maybe, they will break the contract with these 2 companies
[21.03.2013 13:19:10] Antitheist: congratilations narko your SBL was removed
[21.03.2013 13:19:25] narko: after 3 days I’m still moving. I have server from new DC in russia now
[21.03.2013 13:19:31] Antitheist: pin?
[21.03.2013 13:19:34] narko: yes
[21.03.2013 13:20:02] narko: I will not deal with the british datacenters any more
[21.03.2013 13:20:08] narko: even swiftway didn’t give a shit about the SBL
[21.03.2013 13:20:18] narko: but Racksrv treats it like they’re the secret police
[21.03.2013 14:15:03] Yuri: looks spamhaus pissed off
they try to piss everywhere
[21.03.2013 14:15:07] Yuri: SBL179470
217.65.0.0/22 citytelecom.ru
21-Mar-2013 11:59 GMT
Spammer hosting (escalation)
[21.03.2013 14:15:30] narko: is this for providing connectivity to 2×4?
[21.03.2013 14:15:35] narko: or another
[21.03.2013 14:15:41] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: no this is for being russians haha
[21.03.2013 14:15:46] narko: lol
[21.03.2013 14:16:00] Yuri: he provide us and some others.
[21.03.2013 14:16:02] NM: i cant open their site
[21.03.2013 14:42:49] Yuri: i found why
——————
spamahost wrote yesturday in facebook.
One of our VPS nodes is undergoing a node transfer. We are moving the “Zeus” node to a different upstream (which now supports full emailing!), as well as upgraded hardware. Please check your emails for more information, as well as your client areas!
——————-
and his website was on our network.
[21.03.2013 14:42:57] Yuri: so spamhaus pissed on it.
[21.03.2013 15:17:13] narko: i go to feed my addiction to chinese food now.brb
[21.03.2013 15:17:40] narko: when i’m back in few minutes. let’s ddos some more shit
[21.03.2013 15:17:41] narko: (hug)

====================================================================

Spamhaus succeeds in getting Stophaus[dot]org suspended at the domain registry level. This angers Prinz Sven, who begins coming unglued — threatening to attack or harm the domain registrar and anyone else involved in the suspension. Sven even goes so far as to post a manifesto on his Facebook account, taking on the persona of a pirate and lobbing threats of additional DDoS attacks as well as physical violence against Spamhaus members.

[21.03.2013 17:35:41] Antitheist: fuckers
[21.03.2013 17:35:42] narko: fuck! how they did this
[21.03.2013 17:35:56] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: hmm?
[21.03.2013 17:35:57] Antitheist: who are ahnames?
[21.03.2013 17:36:02] narko: advanced hosters ltd
[21.03.2013 17:36:13] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: say what
[21.03.2013 17:36:18] narko: the domain is suspended
[21.03.2013 17:36:22] narko: by the registrar
[21.03.2013 17:36:45] Antitheist: what kind of a shit registrar was it
[21.03.2013 17:36:59] narko: www.ahnames.com
[21.03.2013 17:37:03] Antitheist: webnames.ru or naunet.ru are pissing on spamhaus
[21.03.2013 17:37:13] Antitheist: had to get domain from them
[21.03.2013 17:37:19] narko: well now nothing can be done
[21.03.2013 17:37:21] Antitheist: its still possible to transfer
[21.03.2013 17:37:37] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: then do so
[21.03.2013 17:37:44] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: to -their- domain registrar
[21.03.2013 17:37:56] narko: gandi is a bad registrar
[21.03.2013 17:46:33] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: Domain Name: STOPHAUS.COM

Abuse email: abuse@ahnames.com

DOMAIN SUSPENDED DUE TO VIOLATION OF OUR TOS
Arr! · · Promote
now turn it back on before we send those 80gbit/s down your ass.
[21.03.2013 17:47:02] narko: you have very big balls
[21.03.2013 17:47:12] narko: writing ddos threads on facebook? I would not even do that and I am the person doing th attacks  lol
[21.03.2013 17:47:21] narko: threats *
[21.03.2013 17:47:33] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: who cares, they just ddossed us
[21.03.2013 17:47:40] Yuri: most men in this chat are with big balls.
[21.03.2013 17:47:40] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: by disabling the domain without a proper excuse
[21.03.2013 17:47:44] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: so might as well disable theirs
[21.03.2013 17:47:53] eDataKing: what’s wrong with ahnames?
[21.03.2013 17:47:56] eDataKing: what did they do?
[21.03.2013 17:47:59] narko: they banned the domain
[21.03.2013 17:48:01] Yuri: did somebody stoped our domain ?
[21.03.2013 17:48:02] narko: suspended it
[21.03.2013 17:48:09] Yuri: wtf
[21.03.2013 17:48:10] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: actually i threattened to have steve linford terminated physically a minute before that on my own profile
[21.03.2013 17:48:11] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: lol
[21.03.2013 17:48:14] Yuri: we could change to RU
[21.03.2013 17:48:17] Yuri: stophaus.ru
[21.03.2013 17:48:19] Goo: xD
[21.03.2013 17:48:19] eDataKing: then we should hit them
[21.03.2013 17:48:21] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: just call them and have em turn it back on
[21.03.2013 17:48:26] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: or else we take THEM down
[21.03.2013 17:48:29] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: simple as that
[21.03.2013 17:48:32] narko: we need .com back because it’s already in google, linked in pages, etc
[21.03.2013 17:48:32] eDataKing: suspending the domain is a direct challenge
[21.03.2013 17:48:41] eDataKing: yes, the .com needs up
[21.03.2013 17:49:01] eDataKing: We need to contact ahnames and tell them to allow us to transfer the domain
[21.03.2013 17:49:06] Yuri: we need to transfer it to nic.ru
[21.03.2013 17:49:07] eDataKing: they have allowed it before
[21.03.2013 17:49:13] Yuri: they not slose it.
[21.03.2013 17:49:16] narko: domain transfer takes 5-6 days
[21.03.2013 17:49:18] Yuri: they have balls
[21.03.2013 17:49:21] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: im going to announce ALL of their motherfucking nameservers.
[21.03.2013 17:49:25] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: need to make some changes
[21.03.2013 17:49:27] Yuri: ok
[21.03.2013 17:49:31] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: hmm wait better not do that lol
[21.03.2013 17:49:40] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: that ehm would cost us quite a few peerings haha
[21.03.2013 17:49:49] eDataKing: no, it is way faster
[21.03.2013 17:49:58] narko: it doesnt mtater
[21.03.2013 17:50:00] narko: matter
[21.03.2013 17:50:04] narko: you are already offline from most locations
[21.03.2013 17:50:05] narko: :))
[21.03.2013 17:50:27] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: they responded
[21.03.2013 17:50:50] narko: facebook asks me to log in to see it
[21.03.2013 17:50:51] narko: what a joke
[21.03.2013 17:50:56] narko: i will never register to that site
[21.03.2013 17:51:50] eDataKing: if we show them that we will not tolerate them playing spamhaus games they may see that it could cost them to do so
[21.03.2013 17:52:19] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: Sven Olaf Kamphuis how about, its not a question, we know damn well that steve linford of spamhaus has been spreading lies again, this here undermines our freedom of speech, after all there is nothing on that forum that isn’t done 904903 times as much by spamhaus itself… so, if you’re not with us, you’re against us. turn it back on or we turn YOU OFF.
a few grains o’ sand ago · Arr!
Sven Olaf Kamphuis there is no clause in your TOS that states you have to be friends with ‘spamhaus’
a few grains o’ sand ago · Arr!
Sven Olaf Kamphuis so take your pick… 80gbit/s up your ass, orrrr… turning the domain back on
a few grains o’ sand ago · Arr!
[21.03.2013 17:52:25] eDataKing: perfect Sven
[21.03.2013 17:52:29] eDataKing: that is what they need to hear
[21.03.2013 17:53:01] Yuri: stophaus.org also our domain?
[21.03.2013 17:53:17] Goo: haha nice sven
[21.03.2013 17:53:22] Goo: they will be scared
[21.03.2013 17:53:32] Goo: otherwise they’re fucked haha
[21.03.2013 17:53:56] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: send them a few packets so they know
[21.03.2013 17:54:03] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: narko: ddos on that ahnames for like 1 minute
[21.03.2013 17:54:04] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP:
[21.03.2013 17:54:05] Yuri: also .to – they will not close, they ignore everything
[21.03.2013 17:54:30] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: we;re not gonna change the god damn domain name
[21.03.2013 17:54:35] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: we’re gonna make them turn it back on
[21.03.2013 17:54:37] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: simple as that.
[21.03.2013 17:56:16] Goo: i’m bored, shall i hack spamhaus?
[21.03.2013 17:56:27] Yuri: +1
[21.03.2013 17:56:39] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: goo: sure
[21.03.2013 17:56:44] Goo: alright
[21.03.2013 17:56:48] Goo: Goo grabs some donuts
[21.03.2013 17:56:55] Goo: let do this
[21.03.2013 17:57:34] eDataKing: ok, I just collabed with my buddy here he has a good sugg.
[21.03.2013 18:15:24] Cali: your stophaus is offline.
[21.03.2013 18:15:25] Cali: what happened?
[21.03.2013 18:15:37] narko: the domain got suspended by the registrar
[21.03.2013 18:15:47] Cali: lame.
[21.03.2013 18:16:07] Cali: but you should have never registered a .com
[21.03.2013 18:16:23] Antitheist: its not about the tld its about the registrar
[21.03.2013 18:16:55] Antitheist: normal registrar will not suspend domains because of some stupid threats
[21.03.2013 18:17:33] Yuri: Cali, go other chat
[21.03.2013 18:17:40] Yuri: new one
[21.03.2013 18:17:43] Cali: well if it has not been suspended by the .tld then that’s even more lame.
[21.03.2013 18:17:53] Cali: new one?
[21.03.2013 18:18:25] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: as far as i recall marco rinaudo ran a registrar…
[21.03.2013 18:42:32] Valeriy Uhov: today spamhaus very angry
[21.03.2013 18:42:37] Valeriy Uhov: lists everybody
[21.03.2013 18:43:00] narko: yes they listed /25 of hostkey and /25 of burstnet
[21.03.2013 18:43:02] narko: really angry
[21.03.2013 18:43:14] eDataKing: yeah, they are definitely fighting back
[21.03.2013 18:43:18] Yuri: spamhaus should be blind
[21.03.2013 18:43:39] Yuri: we can make a lit what spamhaus can;t close
[21.03.2013 18:43:44] eDataKing: but why wouldn’t they…this is very likely to be their version of Custard’s Last Stand
[21.03.2013 18:44:11] Yuri: like twitter, email account, icq, facebook, home LAN ADSL IP, domains in the next zones like .ru, .su, .to
[21.03.2013 18:44:27] Valeriy Uhov: .ru and .su it closes
[21.03.2013 18:44:39] Yuri: if botnets- yes. its ok.
[21.03.2013 18:44:45] Yuri: but for other things – they can’t close.
[21.03.2013 18:44:49] Yuri: my layer is the guard.
[21.03.2013 18:44:51] Valeriy Uhov: they close for spam
[21.03.2013 18:44:53] Valeriy Uhov: etc
[21.03.2013 18:44:59] eDataKing: what is spam again?
[21.03.2013 18:45:37] Yuri: for INFORMATION: write to other one chat
[21.03.2013 18:45:47] Valeriy Uhov: which one?
[21.03.2013 18:46:09] Valeriy Uhov: http://en.wikipedia.org/wiki/Spam
[21.03.2013 18:48:50] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: steve linford has -6- people on facebook that like his wikipedia page.
[21.03.2013 18:48:53] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: -6-
[21.03.2013 18:48:56] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: so why even bother lol
[22.03.2013 04:18:56] valeralelin: http://clip2net.com/s/4MLYWZ
[22.03.2013 04:41:13] narko: (party)
[22.03.2013 04:46:07] valeralelin: i can get more documents about sh
[22.03.2013 04:50:22] narko: get a document with his real address on it
[22.03.2013 04:50:25] narko: not some virtual offices
[22.03.2013 04:54:08] edataking: let me see that one
[22.03.2013 04:54:17] edataking: post under his name in the records area
[23.03.2013 16:41:24] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: its running into the 95% percentile bandwith billing on cloudflare’s transits atm
[23.03.2013 16:41:43] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: and cloudflare has network issues, so at some point they’ll have to boot spamhaus as it affects their other clients
[23.03.2013 16:42:00] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: at which point, spamhaus has nowhere else to go that can cover them
[23.03.2013 16:42:13] HRH Prinz Sven Olaf von CyberBunker-Kamphuis MP: i doubt google is stupid enough to take them lol

====================================================================

The Skype chat goes quiet at this point and resumes four weeks later. Narko’s worries about his Skype screen name showing up in a screenshot that eDataKing posted to anti-spam forum turn out to be warranted: It is this very screenshot that authorities in the United Kingdom use to later track him down and arrest him.

In April 2013, Kamphuis is arrested in Spain and eventually sent back to the Netherlands, where he is currently on trial. He publicly denies being involved in launching the attacks on Spamhaus.

Narko was a juvenile when he was arrested by the U.K.’s National Crime Agency (NCA); when the NCA raided Narko’s home, they found his computer still logged in to crime forums, and they seized £70,000 from his bank account (believed to be payments for DDoS attacks). Narko later pleaded guilty to coordinating the attacks, but because of his age and in return for cooperating with the NCA he avoided a jail term.

[26.04.2013 18:36:32] Hephaistos: guys
[26.04.2013 18:36:49] Hephaistos: I just got noticed in the news that sven got arrested
[26.04.2013 18:39:39] ??????? ?????: where in the new
[26.04.2013 18:39:39] ??????? ?????: news
[26.04.2013 18:40:40] Hephaistos:
http://translate.google.be/translate?sl=nl&tl=en&u=http%3A%2F%2Fwww.telegraaf.nl%2Fbinnenland%2F21518021%2F
__Nederlander_aangehouden_in_Spanje_vanwege_cyberaanvallen__.html
[26.04.2013 18:40:43] Hephaistos: dutch news
[26.04.2013 18:45:05] Hephaistos: his large-scale DDoS attacks last
month were also performed on Spamhaus partners in the Netherlands, the
United States and Great Britain. The attackers were using fake IP addresses.
As yet, no evidence that the cyber attack on Spamhaus related to the
attacks are later deployed to include banks, payment system iDeal and
DigiD. The house of the suspect, who lives in Barcelona, ??is examined.
Is expected to K. transferred to the Dutch Public Prosecution Service.
[26.04.2013 19:12:40] Hephaistos: http://translate.google.be/translate?sl=nl&tl=en&u=http%3A//www.om.nl/actueel/nieuws-persberichten/@160856/nederlander/
[26.04.2013 19:18:48] The STOPhaus Movement: I thought something was wrong
[26.04.2013 19:19:02] The STOPhaus Movement: is he arrested or just being searched and forensics?
[26.04.2013 19:19:13] Hephaistos: arrested
[26.04.2013 19:19:19] The STOPhaus Movement:
[26.04.2013 19:19:21] Hephaistos: as far as I can see.
[26.04.2013 19:19:33] Hephaistos: it goes off in twitter
[26.04.2013 19:19:39] The STOPhaus Movement: everyone else is ok though right?
[26.04.2013 19:19:45] Hephaistos: on irc anonops there is a channel #freecb3rob
[26.04.2013 19:19:54] Hephaistos: https://twitter.com/freecb3rob
[26.04.2013 19:20:06] Hephaistos: well I have not seen Narko for 2 days.
[26.04.2013 19:20:16] The STOPhaus Movement:
[26.04.2013 19:20:27 |changed 19:20:34] The STOPhaus Movement: we need an update from him
[26.04.2013 19:20:59] The STOPhaus Movement: narko is never offline that long
[26.04.2013 19:21:26] Hephaistos: thing is that I cannot connect to his irc server either.
[26.04.2013 19:21:56] The STOPhaus Movement: I thought anonops was talking shit about Sven promoting CB via STOP when I saw the chatroom?
[26.04.2013 19:22:12 | changed 19:22:22] The STOPhaus Movement: Now there is a channel. I am glad, but that’s some flip-flop stuff right there
[26.04.2013 19:22:14] Hephaistos: well I created the channel
[26.04.2013 19:22:22] Hephaistos: if they have a problem with me .. bring it on
[26.04.2013 19:22:22] The STOPhaus Movement: oh ok
[26.04.2013 19:22:29] The STOPhaus Movement: lulz
[26.04.2013 19:22:40] The STOPhaus Movement: Self-righteous assholes
[26.04.2013 19:28:44] Cali: Sven from cb3rob has been arrested.
[26.04.2013 19:40:19] Hephaistos: Sven = cb3rob
[26.04.2013 19:40:47] Cali: yeah
[26.04.2013 19:40:49] Cali: so he’s been stopped
[26.04.2013 19:40:52] Cali: in Spain.
[26.04.2013 19:40:57] Hephaistos: yes
[26.04.2013 19:41:05] NM: Is it truth? Not fake?
[26.04.2013 19:41:13] Cali: it is in dutch news.
[26.04.2013 19:41:16] Hephaistos: it is truth
[26.04.2013 19:41:21] Hephaistos: and all over twitter
[26.04.2013 19:43:13] Hephaistos: https://twitter.com/search?q=%23freecb3rob&src=hash
[26.04.2013 20:27:00] Hephaistos: http://www.ibtimes.co.uk/articles/461848/20130426/spamhaus-suspect-arrests-spain-kamphuis.htm
[26.04.2013 20:29:30] Yuri: heh.
[26.04.2013 20:30:07] Hephaistos: On twitter “Sven Olaf Kamphuis #freecb3rob possible source behind
record braking 300gbps #DDos arrested. #Anonymous will now try and break that record!”
[26.04.2013 20:32:31] Cali: So, it has made some PR for spamhaus.
[26.04.2013 20:32:37] Cali: that sucks.
[26.04.2013 20:34:06] Hephaistos: negative is still good.
[26.04.2013 20:34:36] Cali: this information has gone to press and media.
[26.04.2013 20:34:48] Cali: thus to the people
[26.04.2013 20:34:58] Hephaistos: well once they read what stophaus is.
[26.04.2013 20:35:05] Cali: who are at 90% dumb.
[26.04.2013 20:35:09] Hephaistos: true
[26.04.2013 20:35:14] Hephaistos: You got a point there
[26.04.2013 20:35:15] Cali: So now that make them think that spamhaus is doing well.
[26.04.2013 20:41:22] Hephaistos: pastebin.com/qzhcE1nV
[26.04.2013 20:41:25] Hephaistos: more badnews
[26.04.2013 20:41:56] Cali: Who has written that?
[26.04.2013 20:42:09] Hephaistos: I have no idea.
[26.04.2013 20:42:23] Hephaistos: its over the news everyone is freaking out
[26.04.2013 20:42:25] Cali: It seems to have be written by a 12 years old.
[26.04.2013 20:42:31] Cali: been*
[26.04.2013 20:42:52] Hephaistos: correct, seems like a trol to me. But tell that to the media
[26.04.2013 20:43:03] Hephaistos: and the 90% dumb people
[26.04.2013 20:43:09] Cali: Also I don’t understand.
[26.04.2013 20:43:23] Cali: How is it possible to get such reflection in media by posting something on pastebin?
[26.04.2013 20:43:37] Cali: So if I post that I am going to attack the U.S on pastebin, I would be in the news?
[26.04.2013 20:43:58] Hephaistos: Well, thing is that people think that banks will be ddosed and cannot get their
money. So their hoping that there will be a bankrun.
[26.04.2013 20:44:45] Cali: It is very doubtful that DDoSing the website of a bank will prevent the bank from operating.
[26.04.2013 20:46:45] Hephaistos: it will cost the bank money
[26.04.2013 20:47:32] Cali: Maybe to crap bank.
[26.04.2013 20:48:07] Cali: it will be insignifiant
[26.04.2013 20:48:11] Cali: insignificant.
[26.04.2013 18:21:36] Erik Bais: http://www.om.nl/actueel/nieuws-persberichten/@160856/nederlander/
[26.04.2013 18:26:15] Yuri: wtf
[26.04.2013 18:26:42] Yuri: is that about sven?
[26.04.2013 18:26:53] Erik Bais: looks like it.
[26.04.2013 18:27:03] NM: what does it mean?)))
[26.04.2013 18:28:17] Yuri: looks like some new that somebody got arrested becouse of some attacks of spamhaus…
heh… looks spamhaus has long hands.
[26.04.2013 18:29:49] Yuri: not so fine.
[26.04.2013 18:31:11] Yuri: afk
[26.04.2013 18:31:44] Yuri: Eric, can you call Sven and check if he is available?
[26.04.2013 18:31:55] Erik Bais: yes.
[26.04.2013 18:32:30] Erik Bais: I also just asked Twisted on Skype. he didn’t knew about it..
He hasn’t spoken to him yet today (he did yesterday) ..
[26.04.2013 18:33:59] Erik Bais: his spanish nr is not working (I get a message in spanish .. ) could be because the number is off.
[26.04.2013 21:51:16] Erik Bais: http://pastebin.com/qzhcE1nV
[26.04.2013 21:51:51] Erik Bais: http://www.telegraaf.nl/binnenland/21518021/__Arrest_NL_er_cyberaanvallen__.html
[26.04.2013 21:52:11] Erik Bais: http://tweakers.net/nieuws/88767/nederlander-opgepakt-voor-ddos-aanvallen-spamhaus.html
[26.04.2013 21:53:32] Erik Bais: http://krebsonsecurity.com/2013/04/dutchman-arrested-in-spamhaus-ddos/
[26.04.2013 21:53:50] Yuri: shit is going on..
[26.04.2013 21:56:17] Erik Bais: where did the pastbin thing came from ? Any idea ?
[26.04.2013 22:02:14] Yuri: don’t know
[26.04.2013 22:02:46] Yuri: may be we should use other system for chat?
[26.04.2013 22:18:07] Erik Bais: they have taken all his phones, data carriers and servers / computers located in Spain..
[26.04.2013 22:18:24] WebExxpurts: what is patebin
[26.04.2013 22:18:25] WebExxpurts: pastebin
[26.04.2013 22:18:39] Erik Bais: [26 April 2013 21:51] Erik Bais: <<< http://pastebin.com/qzhcE1nV
[26.04.2013 22:18:50] WebExxpurts: i mean who created that?
[26.04.2013 22:19:21] Erik Bais: no idea. I got it pasted from someone.. and it is also linked in various media outings on the Netherlands.
[26.04.2013 22:20:27] WebExxpurts: who is someone? that is interested
[26.04.2013 22:20:33] WebExxpurts: what sven did?
[26.04.2013 22:20:53] WebExxpurts: nonsense reports
[26.04.2013 22:21:20] Erik Bais: I got it from Xennt
[26.04.2013 22:21:45] Erik Bais: the owner of Cyberbunker. he got it linked by someone (I don’t know who. )
[26.04.2013 22:24:55] WebExxpurts: i m sure that sven is mistaken identity and authority have made mistake

====================================================================

To my knowledge, nobody else associated with this attack has been arrested or brought to justice. This chat log is fascinating because it highlights how easy it has been and remains for cybercriminals to commit massively disruptive attacks and get away with it.

These days, some of the biggest and most popular DDoS attack resources are in the hands of a few young men operating DDoS-for-hire “booter” or “stresser” services that in some cases accept both credit cards and PayPal, as well as Bitcoin. An upcoming investigation to be published soon by KrebsOnSecurity will provide perhaps the most detailed look yet at the this burgeoning and quite profitable industry. Stay tuned!

Further reading (assuming your eyes still work after this wall of text):

The Guardian: The Man Accused of Breaking the Internet

The Daily Beast: Yeah, We Broke the Internet: The Inside Story of the Biggest Attack Ever

Also, if you enjoy reading this kind of thing, you’ll probably get a kick out of Spam Nation.

Update, 7:40 p.m. ET: Corrected reference to NANAE anti-spam list.
Top

FreeBSD 11.0-RC2 Available

Postby Webmaster Team via FreeBSD News Flash »

The second RC build for the FreeBSD 11.0 release cycle is now available. ISO images for the amd64, armv6, i386, aarch64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.
Top

United Airlines Sets Minimum Bar on Security

Postby BrianKrebs via Krebs on Security »

United Airlines has rolled out a series of updates to its Web site that the company claims will help beef up the security of customer accounts. But at first glance, the core changes — moving from a 4-digit PINs to password and requiring customers to pick five different security questions and answers — may seem like a security playbook copied from Yahoo.com, circa 2009. Here’s a closer look at what’s changed in how United authenticates customers, and hopefully a bit of insight into what the nation’s fourth-largest airline is trying to accomplish with its new system.

United, like many other carriers, has long relied on a frequent flyer account number and a 4-digit personal identification number (PIN) for authenticating customers at its Web site. This has left customer accounts ripe for takeover by crooks who specialize in hacking and draining loyalty accounts for cash.

Earlier this year, however, United began debuting new authentication systems wherein customers are asked to pick a strong password and to choose from five sets of security questions and pre-selected answers. Customers may be asked to provide the answers to two of these questions if they are logging in from a device United has never seen associated with that account, trying to reset a password, or interacting with United via phone.

Some of the questions and answers United come up with.
Yes, you read that right: The answers are pre-selected as well as the questions. For example, to the question “During what month did you first meet your spouse or significant other,” users may select only from one of…you guessed it — 12 answers (January through December).

The list of answers to another security question, “What’s your favorite pizza topping,” had me momentarily thinking I using a pull down menu at Dominos.com — waffling between “pepperoni” and “mashed potato.” (Fun fact: If you were previously unaware that mashed potatoes qualify as an actual pizza topping, United has you covered with an answer to this bit of trivia in its Frequently Asked Questions page on the security changes.)

I recorded a short video of some of these rather unique questions and answers.

United said it opted for pre-defined questions and answers because the company has found “the majority of security issues our customers face can be traced to computer viruses that record typing, and using predefined answers protects against this type of intrusion.”

This struck me as a dramatic oversimplification of the threat. I asked United why they stated this, given that any halfway decent piece of malware that is capable of keylogging is likely also doing what’s known as “form grabbing” — essentially snatching data submitted in forms — regardless of whether the victim types in this information or selects it from a pull-down menu.

Benjamin Vaughn, director of IT security intelligence at United, said the company was randomizing the questions to confound bot programs that seek to automate the submission of answers, and that security questions answered wrongly would be “locked” and not asked again. He added that multiple unsuccessful attempts at answering these questions could result in an account being locked, necessitating a call to customer service.

United said it plans to use these same questions and answers — no longer passwords or PINs — to authenticate those who call in to the company’s customer service hotline. When I went to step through United’s new security system, I discovered my account was locked for some reason. A call to United customer service unlocked it in less than two minutes. All the agent asked me for was my frequent flyer number and my name.

(Incidentally, United still somewhat relies on “security through obscurity” to protect the secrecy of customer usernames by very seldom communicating the full frequent flyer number in written and digital communications with customers. I first pointed this out in my story about the data that can be gleaned from a United boarding pass barcode, because while the full frequent flyer number is masked with “x’s” on the boarding pass, the full number is stored on the pass’s barcode).

Conventional wisdom dictates that what little additional value security questions add to the equation is nullified when the user is required to choose from a set of pre-selected answers. After all, the only sane and secure way to use secret questions if one must is to pick answers that are not only incorrect and/or irrelevant to the question, but that also can’t be guessed or gleaned by collecting facts about you from background checking sites or from your various social media presences online.

Google published some fascinating research last year that spoke to the efficacy and challenges of secret questions and answers, concluding that they are “neither secure nor reliable enough to be used as a standalone account recovery mechanism.”

Overall, the Google research team found the security answers are either somewhat secure or easy to remember—but rarely both. Put another way, easy answers aren’t secure, and hard answers aren’t as useable.

But wait, you say: United asks you to answer up to five security questions. So more security questions equals more layers for the bad guys to hack through, which equals more security, right? Well, not so fast, the Google security folks found.

“When users had to answer both together, the spread between the security and usability of secret questions becomes increasingly stark,” the researchers wrote. “The probability that an attacker could get both answers in ten guesses is 1%, but users will recall both answers only 59% of the time. Piling on more secret questions makes it more difficult for users to recover their accounts and is not a good solution, as a result.”

Vaughn said the beauty of United’s approach is that it uniquely addresses the problem identified by Google researchers — that so many people in the study had so much trouble remembering the answers — by providing users with a set of pre-selected answers from which to choose.

An infographic from Google’s research study on secret questions. Source: Google.
The security team at United reached out a few weeks back to highlight the new security changes, and in a conversation this week they asked what I thought about their plan. I replied that if United is getting pushback from security experts and tech publications about its approach, that’s probably because security people are techies/nerds at heart, and techies/nerds want options and stuff. Or at least the ability to add, enable or disable certain security features.

But the reality today is that almost any security system designed for use by tens of millions of people who aren’t techies is always going to cater to the least sophisticated user on the planet — and that’s about where the level of security for that system is bound to stay for a while.

So I told the United people that I was a somewhat despondent about this reality, mainly because I end up having little other choice but to fly United quite often.

“At the scale that United faces, we felt this approach was really optimal to fix this problem for our customers,” Vaughn said. “We have to start with something that is universally available to our customers. We can’t sent a text message to you when you’re on an airplane or out of the country, we can’t rely on all of our customers to have a smart phone, and we didn’t feel it would be a great use of our customers’ time to send them in the mail 93 million secure ID tokens. We felt a powerful onus to do something, and the something we implemented we feel improves security greatly, especially for non-technical savvy customers.”

Arlan McMillan, United’s chief information security officer, said the basic system that the company has just rolled out is built to accommodate additional security features going forward. McMillan said United has discussed rolling out some type of app-based time-based one-time password (TOTP) systems (Google Authenticator is one popular TOTP example).

“It is our intent to provide additional capabilities to our customers, and to even bring in additional security controls if [customers] choose to,” McMillan said. “We set the minimum bar here, and we think that’s a higher bar than you’re going to find at most of our competitors. And we’re going to do more, but we had to get this far first.”

Lest anyone accuse me of claiming that the thrust of this story is somehow newsy, allow me to recommend some related, earlier stories worth reading about United’s security changes:

TechCrunch: It’s Time to Publicly Shame United Airlines’ So-called Online Security

Slate: United Airlines Uses Multiple Choice Security Questions
Top

A Life or Death Case of Identity Theft?

Postby BrianKrebs via Krebs on Security »

Identity thieves have perfected a scam in which they impersonate existing customers at retail mobile phone stores, pay a small cash deposit on pricey new phones, and then charge the rest to the victim’s account. In most cases, switching on the new phones causes the victim account owner’s phone(s) to go dead. This is the story of a Pennsylvania man who allegedly died of a heart attack because his wife’s phone was switched off by ID thieves and she was temporarily unable to call for help.

On Feb. 20, 2016, James William Schwartz, 84, was going about his daily routine, which mainly consisted of caring for his wife, MaryLou. Mrs. Schwartz was suffering from the end stages of endometrial cancer and wasn’t physically mobile without assistance. When Mr. Schwartz began having a heart attack that day, MaryLou went to use her phone to call for help and discovered it was completely shut off.

Little did MaryLou know, but identity thieves had the day before entered a “premium authorized Verizon dealer” store in Florida and impersonated the Schwartzes. The thieves paid a $150 cash deposit to “upgrade” the elderly couple’s simple mobiles to new iPhone 6s devices, with the balance to be placed on the Schwartz’s account.

“Despite her severely disabled and elderly condition, MaryLou Schwartz was finally able to retrieve her husband’s cellular telephone using a mechanical arm,” reads a lawsuit (PDF) filed in Beaver County, Penn. on behalf of the Schwartz’s two daughters, alleging negligence by the Florida mobile phone store. “This monumental, determined and desperate endeavor to reach her husband’s working telephone took Mrs. Schwartz approximately forty minutes to achieve due to her condition. This vital delay in reaching emergency help proved to be fatal.”

By the time paramedics arrived, Mr. Schwartz was pronounced dead. MaryLou Schwartz died seventeen days later, on March 8, 2016. Incredibly, identity thieves would continue robbing the Schwartzes even after they were both deceased: According to the lawsuit, on April 14, 2016 the account of MaryLou Schwartz was again compromised and a tablet device was also fraudulently acquired in MaryLou’s name.

The Schwartz’s daughters say they didn’t learn about the fraud until after both parents passed away. According to them, they heard about it from the guy at a local Verizon reseller that noticed his longtime customers’ phones had been deactivated. That’s when they discovered that while their mother’s phone was inactive at the time of her father’s death, their father’s mobile had inexplicably been able to make but not receive phone calls.

KNOW YOUR RIGHTS AND OPTIONS

Exactly what sort of identification was demanded of the thieves who impersonated the Schwartzes is in dispute at the moment. But it seems clear that this is a fairly successful and common scheme for thieves to steal (and, in all likelihood, resell) high-end phones.

Lorrie Cranor, chief technologist for the U.S. Federal Trade Commission, was similarly victimized this summer when someone walked into a mobile phone store, claimed to be her, asked to upgrade her phones and walked out with two brand new iPhones assigned to her telephone numbers.

“My phones immediately stopped receiving calls, and I was left with a large bill and the anxiety and fear of financial injury that spring from identity theft,” Cranor wrote in a blog on the FTC’s site.  Cranor’s post is worth a read, as she uses the opportunity to explain how she recovered from the identity theft episode.

She also used her rights under the Fair Credit Reporting Act, which requires that companies provide business records related to identity theft to victims within 30 days of receiving a written request. Cranor said the mobile store took about twice that time to reply, but ultimately explained that the thief had used a fake ID with Cranor’s name but the impostor’s photo.

“She had acquired the iPhones at a retail store in Ohio, hundreds of miles from where I live, and charged them to my account on an installment plan,” Cranor wrote. “It appears she did not actually make use of either phone, suggesting her intention was to sell them for a quick profit. As far as I’m aware the thief has not been caught and could be targeting others with this crime.”

Cranor notes that records of identity thefts reported to the FTC provide some insight into how often thieves hijack a mobile phone account or open a new mobile phone account in a victim’s name.

“In January 2013, there were 1,038 incidents of these types of identity theft reported, representing 3.2% of all identity theft incidents reported to the FTC that month,” she explained. “By January 2016, that number had increased to 2,658 such incidents, representing 6.3% of all identity thefts reported to the FTC that month.  Such thefts involved all four of the major mobile carriers.”

The reality, Cranor said, is that identity theft reports to the FTC likely represent only the tip of a much larger iceberg. According to data from the Identity Theft Supplement to the 2014 National Crime Victimization Survey conducted by the U.S. Department of Justice, less than 1% of identity theft victims reported the theft to the FTC.

While dealing with diverted calls can be a hassle, having your phone calls and incoming text messages siphoned to another phone also can present new security problems, thanks to the growing use of text messages in authentication schemes for financial services and other accounts.

Perhaps the most helpful part of Cranor’s post is a section on the security options offered by the four major mobile providers in the U.S. For example, AT&T offers an “extra security” feature that requires customers to present a custom passcode when dealing with the wireless provider via phone or online.

“All of the carriers have slightly different procedures but seem to suffer from the same problem, which is that they’re relying on retail stores relying on store employee to look at the driver’s license,” Cranor told KrebsOnSecurity. “They don’t use services that will check the information on the drivers license, and so that [falls to] the store employee who has no training in spotting fake IDs.”

Some of the security options offered by the four major providers. Source: FTC.
It’s important to note that secret passcodes often can be bypassed by determined attackers or identity thieves who are adept at social engineering — that is, tricking people into helping them commit fraud.

I’ve used a six-digit passcode for more than two years on my account with AT&T, and last summer noticed that I’d stopped receiving voicemails. A call to AT&T’s customer service revealed that all voicemails were being forwarded to a number in Seattle that I did not recognized or authorize.

Since it’s unlikely that the attackers in this case guessed my six-digit PIN, they likely tricked a customer service representative at AT&T into “authenticating” me via other methods — probably by offering static data points about me such as my Social Security number, date of birth, and other information that is widely available for sale in the cybercrime underground on virtually all Americans over the age of 35. In any case, Cranor’s post has inspired me to exercise my rights under the FCRA and find out for certain.

Vineetha Paruchuri, a masters in computer science student at Dartmouth College, recently gave a talk at the Bsides security conference in Las Vegas on her research into security at the major U.S. mobile phone providers. Paruchuri said all of the major mobile providers suffer from a lack of strict protocols for authenticating customers, leaving customer service personnel exposed to social engineering.

“As a computer science student, my contention was that if we take away the control from the humans, we can actually make this process more secure,” Paruchuri said.

Paruchuri said perhaps the most dangerous threat is the smooth-talking social engineer who spends time collecting information about the verbal shorthand or mobile industry patois used by employees at these companies. The thief then simply phones up customer support and poses as a mobile store technician or employee trying to assist a customer. This was the exact approach used in 2014, when young hooligans tricked my then-ISP Cox Communications into resetting the password for my Cox email account.

I suppose one aspect of this problem that makes the lack of strong customer authentication measures by the mobile industry so frustrating is that it’s hard to imagine a device which holds more personal and intimate details about you than your wireless phone. After all, your phone likely knows where you were last night, when you last traveled, the phone number you last called and numbers you most frequently text.

And yet, the best the mobile providers and their fleet of reseller stores can do to tell you apart from an ID thief is to store a PIN that could be bypassed by clever social engineers (who may or may not be shaving yet).

A NOTE FOR AT&T READERS

By the way, readers with AT&T phones may have received a notice this week that AT&T is making some changes to “authorized users” allowed on accounts. The notice advised that starting Sept. 1, 2016, customers can designate up to 10 authorized users per account.

“If your Authorized User does not know your account passcode or extra security passcode, your Authorized User may still access your account in a retail store using a Forgotten Passcode process. Effective Nov. 5, 2016, Authorized Users and those persons who call into Customer Service and provide sufficient account information (“Authenticated Callers”) Will have the ability to add a new line of service to your account. Such requests, whether made by you, an Authorized User, an Authenticated Caller or someone with online access to your account, will trigger a credit check on you.”

AT&T’s message this week about upcoming account changes.
I asked AT&T about what need this new policy was designed to address, and the company responded that AT&T has made no changes to how an authorized user can be added to an account. AT&T spokesman Jim Greer sent me the following:

“With this notice, we are simply increasing the number of authorized users you may add to your account and giving them the ability to add a line in stores or over the phone. We made this change since more customers have multiple lines for multiple people. Authorized users still cannot access the account holder’s sensitive personal information.”

“Over the past several years, the authentication process has been strengthened. In stores, we’re safeguarding customers through driver’s license or other government issued ID authentication.  We use a two-factor authentication when you contact us online or by phone that requires a one-time PIN. We’re continuing our efforts to better protect customers, with additional improvements on the horizon.”

“You don’t have to designate anyone to become an authorized user on your account. You will be notified if any significant changes are made to your account by an authorized user, and you can remove any person as an authorized user at any time.”

The rub is what AT&T does — or more specifically, what the AT&T customer representative does — to verify your identity when the caller says he doesn’t remember his PIN or passcode. If they allow PIN-less authentication by asking for your Social Security number, date of birth and other static information about you, ID thieves can defeat that easily.

Has someone fraudulently ordered phone service or phones in your name? Sound off in the comments below.

If you’re wondering what you can do to shield yourself and your family against identity theft, check out these primers:

How I Learned to Stop Worrying and Embrace the Security Freeze (this primer goes well beyond security freezes and includes a detailed Q&A as well as other tips to help prevent and recover from ID theft).

Are Credit Monitoring Services Worth It? 

What Tax Fraud Victims Can Do

The Lowdown on Freezing Your Kid’s Credit
Top

graphicsmagick: two heap-based buffer overflow in ReadTIFFImage (tiff.c)

Postby ago via agostino's blog »

Description:
Graphicsmagick is an Image Processing System.

A fuzzing revealed two minor issues in the TIFF parser. Both issues come out from different line in the tiff.c file but the problem seemcome from the same origin.

The complete ASan output:

# gm identify $FILE
==6321==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eb12 at pc 0x7fa98ca1fcf4 bp 0x7fff957069a0 sp 0x7fff95706998                                                       
READ of size 1 at 0x60200000eb12 thread T0                                                                                                                                                     
    #0 0x7fa98ca1fcf3 in MagickStrlCpy /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/utility.c:4567:10                                                    
    #1 0x7fa98135de5a in ReadTIFFImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/coders/tiff.c:2060:13                                                       
    #2 0x7fa98c70e06a in ReadImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1607:13                                                     
    #3 0x7fa98c70d6ac in PingImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1370:9                                                      
    #4 0x7fa98c65f5a0 in IdentifyImageCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8372:17                                             
    #5 0x7fa98c663ffb in MagickCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8862:17                                                    
    #6 0x7fa98c6b8ee3 in GMCommandSingle /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17370:10                                                 
    #7 0x7fa98c6b7b78 in GMCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17423:16                                                       
    #8 0x7fa98b5c061f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #9 0x4188d8 in _init (/usr/bin/gm+0x4188d8)                                                                                                                                                
                                                                                                                                                                                               
0x60200000eb12 is located 0 bytes to the right of 2-byte region [0x60200000eb10,0x60200000eb12)                                                                                                
allocated by thread T0 here:                                                                                                                                                                   
    #0 0x4c01a8 in realloc /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:71                                                     
    #1 0x7fa9810ebe5b in _TIFFCheckRealloc /var/tmp/portage/media-libs/tiff-4.0.6/work/tiff-4.0.6/libtiff/tif_aux.c:73

SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/utility.c:4567:10 in MagickStrlCpy


# gm identify $FILE
==26025==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000ecf2 at pc 0x7f07a3aaab3c bp 0x7ffc558602c0 sp 0x7ffc558602b8                                                      
READ of size 1 at 0x60300000ecf2 thread T0                                                                                                                                                     
    #0 0x7f07a3aaab3b in MagickStrlCpy /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/utility.c:4557:7                                                     
    #1 0x7f07983e851c in ReadTIFFImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/coders/tiff.c:2048:13                                                       
    #2 0x7f07a3797a62 in ReadImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1607:13                                                     
    #3 0x7f07a3796f18 in PingImage /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/constitute.c:1370:9                                                      
    #4 0x7f07a36e6648 in IdentifyImageCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8372:17                                             
    #5 0x7f07a36eb01b in MagickCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:8862:17                                                    
    #6 0x7f07a3740a3e in GMCommandSingle /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17370:10                                                 
    #7 0x7f07a373f5bb in GMCommand /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/command.c:17423:16                                                       
    #8 0x7f07a264961f in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.22-r4/work/glibc-2.22/csu/libc-start.c:289                                                                        
    #9 0x4188d8 in _init (/usr/bin/gm+0x4188d8)                                                                                                                                                
                                                                                                                                                                                               
0x60300000ecf2 is located 0 bytes to the right of 18-byte region [0x60300000ece0,0x60300000ecf2)                                                                                               
allocated by thread T0 here:                                                                                                                                                                   
    #0 0x4bfe28 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52                                                      
    #1 0x7f0798178fd4 in setByteArray /var/tmp/portage/media-libs/tiff-4.0.6/work/tiff-4.0.6/libtiff/tif_dir.c:51                                                                              
                                                                                                                                                                                               
SUMMARY: AddressSanitizer: heap-buffer-overflow /var/tmp/portage/media-gfx/graphicsmagick-1.3.24/work/GraphicsMagick-1.3.24/magick/utility.c:4557:7 in MagickStrlCpy
Affected version:
1.3.24 (and maybe past)

Fixed version:
1.3.25

Commit fix:
http://hg.code.sf.net/p/graphicsmagick/code/rev/eb58028dacf5

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.

CVE:
N/A

Timeline:
2016-08-17: bug discovered
2016-08-18: bug reported privately to upstream
2016-08-19: upstream released a patch
2016-08-23: blog post about the issue
2016-09-05: upstream released 1.3.25

Note:
This bug was found with American Fuzzy Lop.

Permalink:

graphicsmagick: two heap-based buffer overflow in ReadTIFFImage (tiff.c)

Top

vc4 status update for 2016-08-22: camera, NIR, testing

Postby Eric Anholt via anholt's lj »

Last week I finally plugged in the camera module I got a while ago to go take a look at what vc4 needs for displaying camera output.

The surprising answer was "nothing."  vc4 could successfully import RGB dmabufs and display them as planes, even though I had been expecting to need fixes on that front.

However, the bcm2835 v4l camera driver needs a lot of work.  First of all, it doesn't use the proper contiguous memory support in v4l (vb2-dma-contig), and instead asks the firmware to copy from the firmware's contiguous memory into vmalloced kernel memory.  This wastes memory and wastes memory bandwidth, and doesn't give us dma-buf support.

Even more, MMAL (the v4l equivalent that the firmware exposes for driving the hardware) wants to output planar buffers with specific padding.  However, instead of using the multi-plane format support in v4l to expose buffers with that padding, the bcm2835 driver asks the firmware to do another copy from the firmware's planar layout into the old no-padding V4L planar format.

As a user of the V4L api, you're also in trouble because none of these formats have any priority information that I can see: The camera driver says it's equally happy to give you RGB or planar, even though RGB costs an extra copy.  I think properly done today, the camera driver would be exposing multi-plane planar YUV, and giving you a mem2mem adapter that could use MMAL calls to turn the planar YUV into RGB.

For now, I've updated the bug report with links to the demo code and instructions.

I also spent a little bit of time last week finishing off the series to use st/nir in vc4.  I managed to get to no regressions, and landed it today.  It doesn't eliminate TGSI, but it does mean TGSI is gone from the normal GLSL path.

Finally, I got inspired to do some work on testing.  I've been doing some free time work on servo, Mozilla's Rust-based web browser, and their development environment has been a delight as a new developer.  All patch submissions, from core developers or from newbies, go through github pull requests.  When you generate a PR, Travis builds and runs the unit tests on the PR.  Then a core developer reviews the code by adding a "r" comment in the PR or provides feedback.  Once it's reviewed, a bot picks up the pull request, tries merging it to master, then runs the full integration test suite on it.  If the test suite passes, the bot merges it to master, otherwise the bot writes a comment with a link to the build/test logs.

Compare this to Mesa's development process.  You make a patch.  You file it in the issue tracker and it gets utterly ignored.  You complain, and someone tells you you got the process wrong, so you join the mailing list and send your patch (and then get a flood of email until you unsubscribe).  It gets mangled by your email client, and you get told to use git-send-email, so you screw around with that for a while before you get an email that will actually show up in people's inboxes.  Then someone reviews it (hopefully) before it scrolls off the end of their inbox, and then it doesn't get committed anyway because your name was familiar enough that the reviewer thought maybe you had commit access.  Or they do land your patch, and it turns out you hasn't run the integration tests and then people complain at you for not testing.

So, as a first step toward making a process like Mozilla's possible, I put some time into fixing up Travis on Mesa, and building Travis support for the X Server.  If I can get Travis to run piglit and ensure that expected-pass tests don't regress, that at least gives us a documentable path for new developers in these two projects to put their code up on github and get automated testing of the branches they're proposing on the mailing lists.
Top

libav: stack-based buffer overflow in aac_sync (aac_parser.c)

Postby ago via agostino's blog »

Description:
Libav is an open source set of tools for audio and video processing.

A crafted file causes a stack-based buffer overflow. The ASan report may be confused because it mentions get_bits, but the issue is in aac_sync.
This issue was discovered the past year, I reported it to Luca Barbato privately and I didn’t follow the state.
Before I made the report, the bug was noticed by Janne Grunau because the fate test reported a failure, then he fixed it, but at that time there wasn’t stable release(s) that included the fix.

The complete ASan output:

~ # avconv -i $FILE -f null -
==20736==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd3bd34f4a at pc 0x7f0805611189 bp 0x7ffd3bd34e20 sp 0x7ffd3bd34e18
READ of size 4 at 0x7ffd3bd34f4a thread T0
    #0 0x7f0805611188 in get_bits /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/get_bits.h:244:5
    #1 0x7f0805611188 in avpriv_aac_parse_header /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/aacadtsdec.c:58
    #2 0x7f080560f19e in aac_sync /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/aac_parser.c:43:17
    #3 0x7f080560a87b in ff_aac_ac3_parse /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/aac_ac3_parser.c:48:25
    #4 0x7f0806fcd8e6 in av_parser_parse2 /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/parser.c:157:13
    #5 0x7f0808efd4dd in parse_packet /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavformat/utils.c:794:15
    #6 0x7f0808edae64 in read_frame_internal /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavformat/utils.c:960:24
    #7 0x7f0808ee8783 in avformat_find_stream_info /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavformat/utils.c:2156:15
    #8 0x4f62f6 in open_input_file /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv_opt.c:726:11
    #9 0x4f474f in open_files /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv_opt.c:2127:15
    #10 0x4f3f62 in avconv_parse_options /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv_opt.c:2164:11
    #11 0x528727 in main /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/avconv.c:2629:11
    #12 0x7f0803c83aa4 in __libc_start_main /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20/csu/libc-start.c:289
    #13 0x43a5d6 in _start (/usr/bin/avconv+0x43a5d6)

Address 0x7ffd3bd34f4a is located in stack of thread T0 at offset 170 in frame
    #0 0x7f080560ee3f in aac_sync /var/tmp/portage/media-video/libav-11.3/work/libav-11.3/libavcodec/aac_parser.c:31

  This frame has 3 object(s):
    [32, 64) 'bits'
    [96, 116) 'hdr'
    [160, 168) 'tmp' 0x10002779e9e0: 00 00 04 f2 f2 f2 f2 f2 00[f3]f3 f3 00 00 00 00                                                                                                                                                                                                              
  0x10002779e9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                              
  0x10002779ea00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1                                                                                                                                                                                                              
  0x10002779ea10: 00 f2 f2 f2 04 f2 04 f3 00 00 00 00 00 00 00 00                                                                                                                                                                                                              
  0x10002779ea20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                              
  0x10002779ea30: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00                                                                                                                                                                                                              
Shadow byte legend (one shadow byte represents 8 application bytes):                                                                                                                                                                                                           
  Addressable:           00                                                                                                                                                                                                                                                    
  Partially addressable: 01 02 03 04 05 06 07                                                                                                                                                                                                                                  
  Heap left redzone:       fa                                                                                                                                                                                                                                                  
  Heap right redzone:      fb                                                                                                                                                                                                                                                  
  Freed heap region:       fd                                                                                                                                                                                                                                                  
  Stack left redzone:      f1                                                                                                                                                                                                                                                  
  Stack mid redzone:       f2                                                                                                                                                                                                                                                  
  Stack right redzone:     f3                                                                                                                                                                                                                                                  
  Stack partial redzone:   f4                                                                                                                                                                                                                                                  
  Stack after return:      f5                                                                                                                                                                                                                                                  
  Stack use after scope:   f8                                                                                                                                                                                                                                                  
  Global redzone:          f9                                                                                                                                                                                                                                                  
  Global init order:       f6                                                                                                                                                                                                                                                  
  Poisoned by user:        f7                                                                                                                                                                                                                                                  
  Container overflow:      fc                                                                                                                                                                                                                                                  
  Array cookie:            ac                                                                                                                                                                                                                                                  
  Intra object redzone:    bb                                                                                                                                                                                                                                                  
  ASan internal:           fe                                                                                                                                                                                                                                                  
  Left alloca redzone:     ca                                                                                                                                                                                                                                                  
  Right alloca redzone:    cb                                                                                                                                                                                                                                                  
==20736==ABORTING                                                                                                                                                                                                                                                              
Affected version:
11.3 (and maybe past versions)

Fixed version:
11.5

Commit fix:
https://git.libav.org/?p=libav.git;a=commit;h=fb1473080223a634b8ac2cca48a632d037a0a69d

Credit:
This bug was discovered by Agostino Sarubbo of Gentoo.
This bug was also discovered by Janne Grunau.

CVE:
N/A

Timeline:
2015-07-27: bug discovered
2015-07-28: bug reported privately to upstream
2016-08-20: blog post about the issue

Note:
This bug was found with American Fuzzy Lop.
This bug does not affect ffmpeg.
A same fix, was applied to another part of (similar) code in the ac3_parser.c file.

Permalink:

libav: stack-based buffer overflow in aac_sync (aac_parser.c)

Top

Jetson TK1, FreeBSD, and SSD

Postby gonzo via FreeBSD developer's notebook | All Things FreeBSD »

Looks like my attempt to cheap out on SSD for TK1 has backfired. I went for the cheapest SSD available in local store (Toshiba Q300) but when I tried to checkout FreeBSD sources to the drive I got bunch of WRITE_FPDMA_QUEUED timeouts and system locked up. The same thing happened when I tried to perform checkout on Linux. The drive itself was OK, it survived “svn co …/head” and dd when connected using USB-to-SATA adapter.

I believe the problem was that TK1 SATA voltage was out of Toshiba’s tolerance range. I replaced Q300 with Samsung EVO 850 and was able to checkout sources and finish buildworld using SSD for src/obj storage.
Top

Creating a quick DNS server with a Rapsberry Pi2 and FreeBSD 11.0-RC1

Postby Warner Losh via Warner's Random Hacking Blog »

Raspberry Pi 2 and FreeBSD 11 and bind 9.9 for a name server


Just thought I'd outline the steps to bring a Raspberry Pi 2 up with FreeBSD and then create a DNS server with bind. This is for the Raspberry Pi2, but the only difference between this and any other supported board is the file you grab.

The TL;DR version

Download the image, use xz to decompress and dd to a SD card. Boot the SD card with a serial console, create a new account to log into. Install the appropriate packages. Configure named. Tell the world about it (router and registrar). Profit! All quite simple, though there were a few snags that are in the 'Long Version'

Long Version, so much detail


First, download the FreeBSD image from https://www.freebsd.org/where.html. I'm doing the SD Card Image for FreeBSD 11.0-RC1. This gave me the file FreeBSD-11.0-RC1-arm-armv6-RPI2.img.xz in my downloads area. If you're doing a different image, adjust below.

Next, I needed to create a microSD card for the RPi-2. I plugged a 4GB SD Card into my USB adapter, and the device appeared as da2 on my FreeBSD box.
 xz -d < ~/FreeBSD-11.0-RC1-arm-armv6-RPI2.img.xz | sudo dd of=/dev/da2 bs=1m
will uncompress it and splat it onto the SD card.

Next, I connected to my RPi2's serial port with tip and the Adafruit USB to TTY Adapter:
tip -115200 ucom1
When booting, I got this log. Yours might not be identical, but the login: at the end should be the same.


U-Boot 2015.04 (Aug 12 2016 - 16:50:57)

DRAM:  944 MiB
WARNING: Caches not enabled
RPI 2 Model B
MMC:   bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:    serial
Out:   lcd
Err:   lcd
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0 
Booting from: mmc 0 ubldr
reading ubldr
272013 bytes read in 213 ms (1.2 MiB/s)
## Starting application at 0x02000098 ...
Consoles: U-Boot console  
Compatible U-Boot API signature found @0x3ab4a4c8

FreeBSD/armv6 U-Boot loader, Revision 1.2
(root@releng2.nyi.freebsd.org, Fri Aug 12 17:05:59 UTC 2016)

DRAM: 944MB
Number of U-Boot devices: 1
U-Boot env: loaderdev='mmc 0'
Found U-Boot device: disk
  Checking unit=0 slice= partition=... good.
Booting from disk0s2a:
/boot/kernel/kernel data=0x72a864+0x17979c syms=[0x4+0x7e120+0x4+0x90fad]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by U-Boot at address 0x100.
Kernel entry at 0x0x2200100...
Kernel args: (null)
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-RC1 #0 r303979: Fri Aug 12 17:12:13 UTC 2016
    root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
VT: init without driver.
sema_sysinit
CPU: Cortex A7 rev 5 (Cortex-A core)
 Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
 WB enabled LABT branch prediction disabled
LoUU:2 LoC:3 LoUIS:2 
Cache level 1: 
 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
 32KB/32B 2-way instruction cache Read-Alloc
Cache level 2: 
 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
real memory  = 989851648 (943 MB)
avail memory = 956411904 (912 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0:
simplebus0: mem 0x3f000000-0x3fffffff on ofwbus0
local_intc0: mem 0x40000000-0x400000ff on simplebus0
generic_timer0: on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000
intc0: mem 0xb200-0xb3ff on simplebus0
bcmwd0: mem 0x10001c-0x100027 on simplebus0
gpio0: mem 0x200000-0x2000af on simplebus0
gpio0: read-only pins: 46,48-53.
gpio0: reserved pins: 48-53.
gpiobus0: on gpio0
gpioled0: at pin 35 on gpiobus0
gpioled1: at pin 47 on gpiobus0
gpioc0: on gpio0
iichb0: mem 0x205000-0x20501f on simplebus0
iicbus0: on iichb0
iic0: on iicbus0
iichb1: mem 0x804000-0x80401f on simplebus0
iicbus1: on iichb1
iic1: on iicbus1
spi0: mem 0x204000-0x20401f on simplebus0
spibus0: on spi0
bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff on simplebus0
mbox0: mem 0xb880-0xb8bf on simplebus0
sdhci_bcm0: mem 0x300000-0x3000ff on simplebus0
mmc0: on sdhci_bcm0
uart0: mem 0x201000-0x201fff on simplebus0
uart0: console (115200,n,8,1)
vchiq0: mem 0xb800-0xb84f on simplebus0
vchiq: local ver 8 (min 3), remote ver 8.
pcm0: on vchiq0
bcm283x_dwcotg0: mem 0x980000-0x99ffff on simplebus0
usbus0 on bcm283x_dwcotg0
cpulist0: on ofwbus0
cpu0: on cpulist0
bcm2835_cpufreq0: on cpu0
cpu1: on cpulist0
cpu2: on cpulist0
cpu3: on cpulist0
fb0: on ofwbus0
fbd0 on fb0
VT: initialize with new VT driver "fb".
fb0: 1824x984(1824x984@0,0) 24bpp
fb0: fbswap: 1, pitch 5472, base 0x3d359000, screen_size 5428224
cryptosoft0:
Timecounters tick every 10.000 msec
usbus0: 480Mbps High Speed USB v2.0
ugen0.1: at usbus0
uhub0: on usbus0
mmcsd0: 4GB at mmc0 41.6MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
Release APs
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
warning: no time-of-day clock registered, system time will not be set accurately
uhub0: 1 port with 1 removable, self powered
Growing root partition to fill device
GEOM_PART: mmcsd0s2 was automatically resized.
  Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them.
mmcsd0s2 resized
ugen0.2: at usbus0
uhub1: on usbus0
uhub1: MTT enabled
mmcsd0s2a resized
super-block backups (for fsck_ffs -b #) at:
 1994944, 2493632, 2992320, 3491008,uhub1: 5 ports with 4 removable, self powered
 3989696, 4488384, 4987072, 5485760,
 5984448, 6483136, 6981824, 7480512
ugen0.3: at usbus0
smsc0: on usbus0
smsc0: chip 0xec00, rev. 0002
miibus0: on smsc0
ukphy0: PHY 1 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: on smsc0
ue0: Ethernet address: b8:27:eb:xx:xx:xx
ugen0.4: at usbus0
ukbd0: on usbus0
kbd1 at ukbd0
/etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one
Setting hostuuid: 3b610f45-60b0-11e6-85fc-b827eb30ec4b.
Setting hostid: 0xd150b3f7.
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 745130 free (266 frags, 93108 blocks, 0.0% fragmentation)
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
random: unblocking device.
Soft Float compatibility ldconfig path:
Setting hostname: rpi2.
Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
smsc0: chip 0xec00, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed to UP
Starting Network: lo0 ue0.
lo0: flags=8049 metric 0 mtu 16384
options=600003
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
inet 127.0.0.1 netmask 0xff000000 
groups: lo 
nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
options=80009
ether b8:27:eb:30:ec:4b
media: Ethernet autoselect (100baseTX )
status: active
nd6 options=29
Starting devd.
Starting dhclient.
DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 10.0.0.5
DHCPOFFER from 10.0.0.3
DHCPREQUEST on ue0 to 255.255.255.255 port 67
DHCPACK from 10.0.0.5
bound to 10.0.0.245 -- renewal in 3600 seconds.
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Generating host.conf.
Creating and/or trimming log files.
Starting syslogd.
Clearing /tmp (X related).
Updating motd:.
Mounting late filesystems:.
Configuring vt: blanktime.
Generating RSA host key.
2048 SHA256:FXp0GIg9YQO8QKDV4laoIrXLhUPcBQPaYeusHOnn4wI root@rpi2 (RSA)
Generating ECDSA host key.
256 SHA256:lYyCJFYZHx2W8slGyhe8CF6GIc8ejZZWcO4wTlRf/YI root@rpi2 (ECDSA)
Generating ED25519 host key.
256 SHA256:L2wqTBkNdGahTGswcpzG4ysvhU9uCPyjBtLGLczi6fI root@rpi2 (ED25519)
Performing sanity check on sshd configuration.
Starting sshd.
Starting cron.
Starting background file system checks in 60 seconds.
mount: /dev/ufs/rootfs: Device busy

Fri Aug 12 17:15:15 UTC 2
FreeBSD/arm (rpi2) (ttyu0)

login: root
Password:
Aug 12 17:15:19 rpi2 login: ROOT LOGIN (root) ON ttyu0
FreeBSD 11.0-RC1 (RPI2) #0 r303979: Fri Aug 12 17:12:13 UTC 2016

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

Edit /etc/motd to change this login announcement.
root@rpi2:~ # adduser
Username: imp
Full name: M Warner Losh
Uid (Leave empty for default): 1234
Login group [imp]: 
Login group is imp. Invite imp into other groups? []: wheel
Login class [default]: 
Shell (sh csh tcsh nologin) [sh]: tcsh
Home directory [/home/imp]: 
Home directory permissions (Leave empty for default): 
Use password-based authentication? [yes]: 
Use an empty password? (yes/no) [no]: 
Use a random password? (yes/no) [no]: 
Enter password: 
Enter password again: 
Lock out the account after creation? [no]: 
Username   : imp
Password   : *****
Full Name  : M Warner Losh
Uid        : 1234
Class      : 
Groups     : imp wheel
Home       : /home/imp
Home Mode  : 
Shell      : /bin/tcsh
Locked     : no
OK? (yes/no): yes
adduser: INFO: Successfully added (imp) to the user database.
Add another user? (yes/no): no
Goodbye!
root@rpi2:~ # logout

FreeBSD/arm (rpi2) (ttyu0)

login: 
 So, now we have a remote login (or we could have used the default freebsd/freebsd user).

Next, we need to bootstrap the packages. In the RC1 release there's a snag. The quarterly release hasn't been created yet, so you have to override the location:
# env PACKAGESITE=pkg+http://pkg.FreeBSD.org/FreeBSD:11:armv6/latest pkg boostrap
The package management tool is not yet installed on your system.Do you want to fetch and install it now? [y/N]: yBootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:11:armv6/latest, please wait...Verifying signature with trusted certificate pkg.freebsd.org.2013102301... doneInstalling pkg-1.8.5_1...Extracting pkg-1.8.5_1: 100%
root@rpi2:/home/imp # 
Now, in the RC1 release, there's another snag, you have to change quarterly to latest in /etc/pkg/FreeBSD.conf. Once you do that, you can continue. Since this is a simple box, I'm just installing sudo, bind99 and emacs-nox11 on it. Don't need anything more than that.

root@rpi2:/home/imp # pkg install sudo bind99 emacs-nox11
Updating FreeBSD repository catalogue...Fetching meta.txz: 100%    944 B   0.9kB/s    00:01    Fetching packagesite.txz: 100%    5 MiB 525.0kB/s    00:09    Processing entries: 100%FreeBSD repository update completed. 21349 packages processed.The following 18 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:sudo: 1.8.17bind99: 9.9.9P1emacs-nox11: 24.5_3,3gettext-runtime: 0.19.8.1indexinfo: 0.2.4libxml2: 2.9.3libedit: 3.1.20150325_2,1idnkit: 1.0_5gnutls: 3.4.13nettle: 3.2gmp: 5.1.3_3ca_root_nss: 3.22.2libtasn1: 4.8trousers: 0.3.13tpm-emulator: 0.7.4_1p11-kit: 0.23.2libffi: 3.2.1libidn: 1.31
The process will require 179 MiB more space.48 MiB to be downloaded.
Proceed with this action? [y/N]: yFetching sudo-1.8.17.txz: 100%  835 KiB 427.4kB/s    00:02    Fetching bind99-9.9.9P1.txz: 100%    4 MiB 583.4kB/s    00:08    Fetching emacs-nox11-24.5_3,3.txz: 100%   36 MiB 574.9kB/s    01:06    Fetching gettext-runtime-0.19.8.1.txz: 100%  142 KiB 145.5kB/s    00:01    Fetching indexinfo-0.2.4.txz: 100%    5 KiB   5.0kB/s    00:01    Fetching libxml2-2.9.3.txz: 100%  735 KiB 376.5kB/s    00:02    Fetching libedit-3.1.20150325_2,1.txz: 100%  107 KiB 110.1kB/s    00:01    Fetching idnkit-1.0_5.txz: 100%  182 KiB 185.9kB/s    00:01    Fetching gnutls-3.4.13.txz: 100%    2 MiB 501.4kB/s    00:04    Fetching nettle-3.2.txz: 100%    1 MiB 378.8kB/s    00:03    Fetching gmp-5.1.3_3.txz: 100%  390 KiB 399.5kB/s    00:01    Fetching ca_root_nss-3.22.2.txz: 100%  323 KiB 330.3kB/s    00:01    Fetching libtasn1-4.8.txz: 100%  584 KiB 298.9kB/s    00:02    Fetching trousers-0.3.13.txz: 100%  390 KiB 399.6kB/s    00:01    Fetching tpm-emulator-0.7.4_1.txz: 100%   18 KiB  18.0kB/s    00:01    Fetching p11-kit-0.23.2.txz: 100%  199 KiB 203.4kB/s    00:01    Fetching libffi-3.2.1.txz: 100%   33 KiB  33.4kB/s    00:01    Fetching libidn-1.31.txz: 100%  196 KiB 200.9kB/s    00:01    Checking integrity... done (0 conflicting)[1/18] Installing indexinfo-0.2.4...[1/18] Extracting indexinfo-0.2.4: 100%[2/18] Installing gmp-5.1.3_3...[2/18] Extracting gmp-5.1.3_3: 100%[3/18] Installing gettext-runtime-0.19.8.1...[3/18] Extracting gettext-runtime-0.19.8.1: 100%[4/18] Installing ca_root_nss-3.22.2...[4/18] Extracting ca_root_nss-3.22.2: 100%[5/18] Installing libtasn1-4.8...[5/18] Extracting libtasn1-4.8: 100%[6/18] Installing tpm-emulator-0.7.4_1...===> Creating groups.Creating group '_tss' with gid '601'.===> Creating usersCreating user '_tss' with uid '601'.[6/18] Extracting tpm-emulator-0.7.4_1: 100%[7/18] Installing libffi-3.2.1...[7/18] Extracting libffi-3.2.1: 100%[8/18] Installing nettle-3.2...[8/18] Extracting nettle-3.2: 100%[9/18] Installing trousers-0.3.13...===> Creating groups.Using existing group '_tss'.===> Creating usersUsing existing user '_tss'.[9/18] Extracting trousers-0.3.13: 100%[10/18] Installing p11-kit-0.23.2...[10/18] Extracting p11-kit-0.23.2: 100%[11/18] Installing libidn-1.31...[11/18] Extracting libidn-1.31: 100%[12/18] Installing libxml2-2.9.3...[12/18] Extracting libxml2-2.9.3: 100%[13/18] Installing libedit-3.1.20150325_2,1...[13/18] Extracting libedit-3.1.20150325_2,1: 100%[14/18] Installing idnkit-1.0_5...[14/18] Extracting idnkit-1.0_5: 100%[15/18] Installing gnutls-3.4.13...[15/18] Extracting gnutls-3.4.13: 100%[16/18] Installing sudo-1.8.17...[16/18] Extracting sudo-1.8.17: 100%[17/18] Installing bind99-9.9.9P1...[17/18] Extracting bind99-9.9.9P1: 100%[18/18] Installing emacs-nox11-24.5_3,3...[18/18] Extracting emacs-nox11-24.5_3,3: 100%Message from ca_root_nss-3.22.2:********************************* WARNING *********************************
FreeBSD does not, and can not warrant that the certification authoritieswhose certificates are included in this package have in any way beenaudited for trustworthiness or RFC 3647 compliance.
Assessment and verification of trust is the complete responsibility of thesystem administrator.
*********************************** NOTE **********************************
This package installs symlinks to support root certificates discovery bydefault for software that uses OpenSSL.
This enables SSL Certificate Verification by client software without manualintervention.
If you prefer to do this manually, replace the following symlinks witheither an empty file or your site-local certificate bundle.
  * /etc/ssl/cert.pem  * /usr/local/etc/ssl/cert.pem  * /usr/local/openssl/cert.pem
***************************************************************************Message from trousers-0.3.13:To run tcsd automatically, add the following line to /etc/rc.conf:
tcsd_enable="YES"
You might want to edit /usr/local/etc/tcsd.conf to reflect your setup.
If you want to use tcsd with software TPM emulator, use the followingconfiguration in /etc/rc.conf:
tcsd_enable="YES"tcsd_mode="emulator"tpmd_enable="YES"
To use TPM, add your_account to '_tss' group like following:
# pw groupadd _tss -m your_accountMessage from idnkit-1.0_5:===>   NOTICE:
The idnkit port currently does not have a maintainer. As a result, it ismore likely to have unresolved issues, not be up-to-date, or even be removed inthe future. To volunteer to maintain this port, please create an issue at:
https://bugs.freebsd.org/bugzilla
More information about port maintainership is available at:
https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-portMessage from bind99-9.9.9P1:***********************************************************************            _  _____ _____ _____ _   _ _____ ___ ___  _   _         **           / \|_   _|_   _| ____| \ | |_   _|_ _/ _ \| \ | |        **          / _ \ | |   | | |  _| |  \| | | |  | | | | |  \| |        **         / ___ \| |   | | | |___| |\  | | |  | | |_| | |\  |        **        /_/   \_\_|   |_| |_____|_| \_| |_| |___\___/|_| \_|        **                                                                    **   BIND requires configuration of rndc, including a "secret" key.   **    The easiest, and most secure way to configure rndc is to run    **   'rndc-confgen -a' to generate the proper conf file, with a new   **            random key, and appropriate file permissions.           **                                                                    **     The /usr/local/etc/rc.d/named script will do that for you.     **                                                                    ***********************************************************************root@rpi2:/home/imp # 
Although it says that the rc.d named script will do it, I went ahead and did the rndc-confgen -a:
root@rpi2:/home/imp # rndc-confgen -awrote key file "/usr/local/etc/namedb/rndc.key" 
next, we need to copy over the master zone and setup named.conf. Briefly, I commented out the part that binds to localhost and added a pointer to the master file for my zone. I setup stuff so secondaries could transfer out, and I could cross-mirror the secondaries.

So, once it was all running right, I changed rc.conf to enable it (as well as tweak the hostname from the default):
named_enable=yes
Now the fun part: telling my router to forward DNS packets (port 53) to my FreeBSD box, and then telling my registrar the new IP address of my DNS server. And after the obligatory password snafu, I was able to get everything up and happy.

Removed the default 'freebsd' account and changed the root password to something useful, and I was done.

A final though

I used to think I'd need to pay someone to host DNS for me. And that used to be cheaper in someone else's colo. However, with dirt cheap boards like the Raspberry Pi 2 and others like it, now I can host it myself for not much more than paying someone else do do it. And setting up the server was super easy. Wish blogspot would allow me to more easily attach text files, but it's an imperfect world.



Top

Malware Infected All Eddie Bauer Stores in U.S., Canada

Postby BrianKrebs via Krebs on Security »

Clothing store chain Eddie Bauer said today it has detected and removed malicious software from point-of-sale systems at all of its 350+ stores in North America, and that credit and debit cards used at those stores during the first six months of 2016 may have been compromised in the breach. The acknowledgement comes nearly six weeks after KrebsOnSecurity first notified the clothier about a possible intrusion at stores nationwide.

On July 5, 2016, KrebsOnSecurity reached out to Bellevue, Wash., based Eddie Bauer after hearing from several sources who work in fighting fraud at U.S. financial institutions. All of those sources said they’d identified a pattern of fraud on customer cards that had just one thing in common: They were all recently used at some of Eddie Bauer’s 350+ locations in the U.S. The sources said the fraud appeared to stretch back to at least January 2016.

A spokesperson for Eddie Bauer at the time said the company was grateful for the outreach but that it hadn’t heard any fraud complaints from banks or from the credit card associations.

Earlier today, however, an outside public relations firm circled back on behalf of Eddie Bauer. That person told me Eddie Bauer — working with the FBI and an outside computer forensics firm — had detected and removed card-stealing malware from cash registers at all of its locations in the United States and Canada.

The retailer says it believes the malware was capable of capturing credit and debit card numbers from customer transactions made at all 350 Eddie Bauer stores in the United States and Canada between January 2, 2016 to July 17, 2016. The company emphasized that this breach did not impact purchases made at the company’s online store eddiebauer.com.

“While not all transactions during this period were affected, out of an abundance of caution, Eddie Bauer is offering identity protection services to all customers who made purchases or returns during this period,” the company said in a press release issued directly after the markets closed in the U.S. today.

Given the volume of point-0f-sale malware attacks on retailers and hospitality firms in recent months, it would be nice if each one of these breach disclosures didn’t look and sound exactly the same. For example, in addition to offering customers the predictable and irrelevant credit monitoring services topped with bland assurances that the “security of our customers’ information is a top priority,” breached entities could offer the cyber defenders of the world just a few details about the attack tools and online staging grounds the intruders used.

That way, other companies could use the information to find out if they are similarly victimized and to stop the bleeding of customer card data as quickly as possible. Eddie Bauer’s spokespeople say the company has no intention of publishing these so-called “indicators of compromise,” but emphasized that Eddie Bauer worked closely with the FBI and outside security experts.

For more on the importance of IOCs in helping to detect and ultimately stymie cybercrime, check out last Saturday’s story about IOCs released by Visa in connection with the recent intrusion at Oracle’s MICROS point-of-sale unit. And for the record, I have no information connecting this breach or any other recent POS malware attack with the breach at Oracle’s MICROS unit. If that changes, hopefully you’ll read about it here first.
Top

Massive Email Bombs Target .Gov Addresses

Postby BrianKrebs via Krebs on Security »

Over the weekend, unknown assailants launched a massive cyber attack aimed at flooding targeted dot-gov (.gov) email inboxes with subscription requests to thousands of email lists. According to experts, the attack — designed to render the targeted inboxes useless for a period of time — was successful largely thanks to the staggering number of email newsletters that don’t take the basic step of validating new signup requests.

These attacks apparently have been going on at a low level for weeks, but they intensified tremendously over this past weekend. This most recent assault reportedly involved more than 100 government email addresses belonging to various countries that were subscribed to large numbers of lists in a short space of time by the attacker(s). That’s according to Spamhaus, an entity that keeps a running list of known spamming operations to which many of the world’s largest Internet service providers (ISPs) subscribe.

What my inbox looked like on Saturday, Aug. 13. Yours Truly and apparently at least 100 .gov email addresses got hit with an email bombing attack.
When Spamhaus lists a swath of Internet address space as a source of junk email, ISPs usually stop routing email for organizations within those chunks of addresses. On Sunday, Spamhaus started telling ISPs to block email coming from some of the largest email service providers (ESPs) — companies that help some of the world’s biggest brands reach customers via email. On Monday, those ESPs soon began hearing from their clients who were having trouble getting their marketing emails delivered.

In two different posts published at wordtothewise.com, Spamhaus explained its reasoning for the listings, noting that a great many of the organizations operating the lists that were spammed in the attack did not bother to validate new signups by asking recipients to click a confirmation link in an email. In effect, Spamhaus reasoned, their lack of email validation caused them to behave in a spammy fashion.

“The issue is the badly-run ‘open’ lists which happily subscribed every address without any consent verification and which now continue as participants in the list-bombing of government addresses,” wrote Spamhaus CEO Steve Linford. It remains unclear whether hacked accounts at ESPs also played a role.

Also writing for wordtothewise.com, Laura Atkins likened email subscription bombs like this to “distributed denial of service” (DDoS) attacks on individuals.

“They get so much mail from different places they are unable to use their mailbox for real mail,” she wrote. “The hostile traffic can’t be blocked because the mail is coming from so many different sources.”

Atkins said over 100 addresses were added to mailing lists, many from Internet addresses outside the United States.

“The volumes I’m hearing here are significantly high that people cannot use their mailboxes. One sender identified fewer than 10 addresses each signed up to almost 10,000 of their customer lists during a 2 week period,” Atkins wrote. “Other senders have identified addresses that look to be part of the harassment campaign and are working to block mail to those addresses and get them off their lists.”

I WAS ON THE LIST, TOO!

Make that 101 targets, apparently. At approximately 9:00 a.m. ET on Saturday, KrebsOnSecurity’s inbox began filling up with new newsletter subscriptions. The emails came in at a rate of about one new message every 2-3 seconds. By the time I’d finished deleting and unsubscribing from the first page of requests, there would be another page or two of new newsletter-related emails. For most of the weekend until I got things under semi-control, my Gmail account was basically useless.

Some of the lists I was signed up for did require confirmation, but the trouble is if you don’t validate the request within a certain time they still send you additional emails reminding you to complete the signup process.

But those that required validation were in the minority, at least in the emails that I saw. I was aghast at how many of these email lists and newsletters did not require me to click a link to verify my subscription. I used Gmail’s “mark as spam and unsubscribe” option to report all of those subscriptions. It’s taken me almost a day’s worth of effort so far to clean up, and I’m still getting one or two new junk newsletters per minute.

Atkins said many ESPs are now asking their customers to tighten signup requirements to include verification, and to comb through their lists for any recent signups that match certain fingerprints associated with this attack.

I have no idea why I’d be on a list of targets, and no one has contacted me about the attack thus far. But this isn’t the first time that KrebsOnSecurity has been the target of an email bombing attack. A very similar deluge was launched specifically at my inbox in July 2012. I later traced that inbox flooding service back to a guy in Ukraine who was intimately involved in selling credit and debit cards stolen in the 2013 breach at Target.

I don’t know who’s responsible for this latest attack, and I’m not suggesting a connection between it and the 2012 attacks I just mentioned. But I do marvel at how little seems to have changed since 2012 in terms of how organizations run their newsletters.  It’s also mind-boggling to ponder how many of these time-wasting attacks are the result of organizations that fail to secure or properly configure their software, technology and services.

In the past week alone, for example, KrebsOnSecurity.com has been the target of more than a half-dozen DDoS attacks aimed at knocking this site offline. These attacks are increasing in both frequency and intensity because the criminals behind them have access to virtually limitless firepower — millions of poorly-configured systems that can be leveraged to flood the target with so much junk traffic that it is rendered unreachable to legitimate visitors.

Let’s hope the ESPs of the world step up and insist that customers using their email infrastructure take a bit more care to ensure they’re part of the solution and not part of the problem. Atkins captures my thoughts on this subject precisely in the conclusion of her writeup on the attacks.

“Internet harassment seems to be a bigger and bigger issue,” she wrote. “I don’t know if it’s because people are being more open about harassment or if it’s actually more common. In either case, it is the responsibility of networks to minimize the harassment. If your network is a conduit for harassment, you need to do something to stop it.”
Top

tmux pane syncing and copy from vertical splits

Postby Dennis Klein via DieTa.Photo - Medium »



tmux is one of the greatest tools you have as sysadmin for your daily work.

Continue reading on DieTa.Photo »
Top

The Meson build system at GUADEC 2016

Postby Nirbheek via Nirbheek’s Rantings »

For the third year in a row, Centricular was at GUADEC, and this year we sponsored the evening party on the final day at Hoepfner’s Burghof! Hopefully everyone enjoyed it as much as we hoped. :)

The focus for me this year was to try and tell people about the work we've been doing on porting GStreamer to Meson and to that end, I gave a talk on the second day about how to build your GNOME app ~2x faster than before.

The talk title itself was a bit of a lie, since most of the talk was about how Autotools is a mess and how Meson has excellent features (better syntax!) and in-built support for most of the GNOME infrastructure to make it easy for people to use it. But for some people the attraction is also that Meson provides better support on platforms such as Windows, and improves build times on all platforms massively; ranging from 2x on Linux to 10-15x on Windows.

Thanks to the excellent people at c3voc.de, the talks were all live-streamed, and you can see my talk at their relive website for GUADEC 2016.

It was heartening to see that over the past year people have warmed up to the idea of using Meson as a replacement for Autotools. Several people said kind and encouraging words to me and Jussi over the course of the conference (it helps that GNOME is filled with a friendly community!). We will continue to improve Meson and with luck we can get rid of Autotools over time.

The best approach, as always, is to start with the simple projects, get familiar with the syntax, and report any bugs you find! We look forward to your bugs and pull requests. ;)
Top

Ceph RGW Hammer->Jewel upgrade: adding realms, periods etc

Postby Robbat2 via Move along, nothing to read »

Some quick notes on upgrading a Hammer-era Ceph RGW setup to Jewel, because the upstream notes don't cover it well. The multisite docs are the closest there is, but here's what I put together instead.

  • The Zone concept has remained the same.
  • A Region is now a Zonegroup.
  • The top-level RegionMap is moved inside the content of a Period
  • Only one Period can be live at a time, and changes are made to a non-live Period
  • The Realm describes which Period is live.
  • Additionally, there can be a default Zonegroup and Zone inside the period, as well as a default Zone inside a Zonegroup.

Initial state, if you were to look on Hammer:
# radosgw-admin region list
{
  "default_info": {
    "default_region": "default"
  },
  "regions": [
    "default"
  ]
}
# radosgw-admin region-map get
{
  "master_region": "default",
  "bucket_quota": {
    "max_objects": -1,
    "enabled": false,
    "max_size_kb": -1
  },
  "user_quota": {
    "max_objects": -1,
    "enabled": false,
    "max_size_kb": -1
  },
  "regions": [
    {
      "val": {
        "zones": [
          {
            "name": "default",
            "log_meta": "false",
            "endpoints": [

            ],
            "bucket_index_max_shards": 31,
            "log_data": "false"
          }
        ],
        "name": "default",
        "endpoints": [
	      "https://CENSORED-1.EXAMPLE.COM",
	      "https://CENSORED-2.EXAMPLE.COM"
        ],
        "api_name": "CENSORED",
        "default_placement": "default-placement",
        "is_master": "true",
        "hostnames": [
	      "CENSORED-1.EXAMPLE.COM",
	      "CENSORED-2.EXAMPLE.COM"
        ],
        "placement_targets": [
          {
            "name": "default-placement",
            "tags": [

            ]
          }
        ],
        "master_zone": ""
      },
      "key": "default"
    }
  ]
}
# radosgw-admin region get --rgw-region=default
{
  "zones": [
    {
      "log_meta": "false",
      "name": "default",
      "bucket_index_max_shards": 31,
      "endpoints": [

      ],
      "log_data": "false"
    }
  ],
  "master_zone": "",
  "is_master": "true",
  "placement_targets": [
    {
      "name": "default-placement",
      "tags": [

      ]
    }
  ],
  "default_placement": "default-placement",
  "name": "default",
  "hostnames": [
	"CENSORED-1.EXAMPLE.COM",
	"CENSORED-2.EXAMPLE.COM"
  ],
  "endpoints": [
    "https://CENSORED-1.EXAMPLE.COM",
    "https://CENSORED-2.EXAMPLE.COM"
  ],
  "api_name": "CENSORED"
}
# radosgw-admin zone get --rgw-region=default --rgw-zone=default
{
  "log_pool": ".log",
  "user_swift_pool": ".users.swift",
  "placement_pools": [
    {
      "val": {
        "data_pool": ".rgw.buckets",
        "data_extra_pool": ".rgw.buckets.extra",
        "index_pool": ".rgw.buckets.index"
      },
      "key": "default-placement"
    }
  ],
  "user_keys_pool": ".users",
  "control_pool": ".rgw.control",
  "domain_root": ".rgw",
  "usage_log_pool": ".usage",
  "gc_pool": ".rgw.gc",
  "system_key": {
    "access_key": "",
    "secret_key": ""
  },
  "intent_log_pool": ".intent-log",
  "user_uid_pool": ".users.uid",
  "user_email_pool": ".users.email"
}


Initial state, if you were to look on Jewel:
# radosgw-admin zone list
{
    "default_info": "",
    "zones": [
        "default"
    ]
}
# radosgw-admin zonegroup list
{
    "default_info": "",
    "zonegroups": [
        "default"
    ]
}
# TODO: fill the rest of this up.

# Now changing stuff up:
# export SYSTEM_ACCESS_KEY=... SYSTEM_SECRET_KEY=...
# radosgw-admin user create \
  --system  
  --uid=zone.user \
  --display-name="Zone User" \
  --access-key=$SYSTEM_ACCESS_KEY \
  --secret=$SYSTEM_SECRET_KEY
{
  "user_id": "zone.user",
  "display_name": "Zone User",
  "email": "",
  "suspended": 0,
  "max_buckets": 1000,
  "auid": 0,
  "subusers": [],
  "keys": [
      {
          "user": "zone.user",
          "access_key": "...",
          "secret_key": "..."
      }
  ],
  "swift_keys": [],
  "caps": [],
  "op_mask": "read, write, delete",
  "system": "true",
  "default_placement": "",
  "placement_tags": [],
  "bucket_quota": {
      "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1
  },
  "user_quota": {
      "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1
  },
  "temp_url_keys": []
}


# radosgw-admin realm create --rgw-realm gold
{
    "id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "name": "gold",
    "current_period": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
    "epoch": 1
}


# radosgw-admin realm list
{
    "default_info": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "realms": [
        "gold"
    ]
}


# radosgw-admin realm get
{
    "id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "name": "gold",
    "current_period": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
    "epoch": 1
}


# radosgw-admin period list
{
    "periods": [
        "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb"
    ]
}


# radosgw-admin period get
{
    "id": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
    "epoch": 1,
    "predecessor_uuid": "",
    "sync_status": [],
    "period_map": {
        "id": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
        "zonegroups": [],
        "short_zone_ids": []
    },
    "master_zonegroup": "",
    "master_zone": "",
    "period_config": {
        "bucket_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        }
    },
    "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "realm_name": "gold",
    "realm_epoch": 1
}


# radosgw-admin period update --master-zone=default --master-zonegroup=default
{
    "id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103:staging",
    "epoch": 1,
    "predecessor_uuid": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
    "sync_status": [],
    "period_map": {
        "id": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
        "zonegroups": [],
        "short_zone_ids": []
    },
    "master_zonegroup": "",
    "master_zone": "",
    "period_config": {
        "bucket_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        }
    },
    "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "realm_name": "gold",
    "realm_epoch": 2
}


# radosgw-admin period prepare
{
    "id": "8fb1cfbc-ad63-4d92-886a-d939cc52862b",
    "epoch": 1,
    "predecessor_uuid": "",
    "sync_status": [],
    "period_map": {
        "id": "8fb1cfbc-ad63-4d92-886a-d939cc52862b",
        "zonegroups": [],
        "short_zone_ids": []
    },
    "master_zonegroup": "",
    "master_zone": "",
    "period_config": {
        "bucket_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        }
    },
    "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "realm_name": "gold",
    "realm_epoch": 1
}

# radosgw-admin zone get --rgw-zonegroup=default --rgw-zone=default >zone.json
# radosgw-admin zonegroup get --rgw-zonegroup=default --rgw-zone=default >zonegroup.json
# $EDITOR zonegroup.json zone.json
## Add the following data:
## both files: Set realm_id
## zone.json: Set system_user.access_key, Set system_user.secret_key
## zonegroup.json: Set master_zone to "default", Set is_master to "true".
# radosgw-admin zone set --rgw-zone=default --rgw-zonegroup=default \
  --realm-id=1ac4fd8d-9e77-4fd2-ad54-b591f1734103 \
  --infile zone.json \
  --master --default
# radosgw-admin zonegroup set --rgw-zonegroup=default \
  --realm-id=1ac4fd8d-9e77-4fd2-ad54-b591f1734103 \
  --infile zonegroup.json \
  --master --default


# radosgw-admin period update
{
    "id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103:staging",
    "epoch": 1,
    "predecessor_uuid": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
    "sync_status": [],
    "period_map": {
        "id": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
        "zonegroups": [
            {
                "id": "default",
                "name": "default",
                "api_name": "CENSORED",
                "is_master": "true",
                "endpoints": [
                    "https:\/\/CENSORED-1.EXAMPLE.COM",
                    "https:\/\/CENSORED-2.EXAMPLE.COM"
                ],
                "hostnames": [
                    "CENSORED-1.EXAMPLE.COM",
                    "CENSORED-2.EXAMPLE.COM"
                ],
                "hostnames_s3website": [],
                "master_zone": "default",
                "zones": [
                    {
                        "id": "default",
                        "name": "default",
                        "endpoints": [],
                        "log_meta": "true",
                        "log_data": "false",
                        "bucket_index_max_shards": 31,
                        "read_only": "false"
                    }
                ],
                "placement_targets": [
                    {
                        "name": "default-placement",
                        "tags": []
                    }
                ],
                "default_placement": "default-placement",
                "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103"
            }
        ],
        "short_zone_ids": [
            {
                "key": "default",
                "val": 2610307010
            }
        ]
    },
    "master_zonegroup": "default",
    "master_zone": "default",
    "period_config": {
        "bucket_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        }
    },
    "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "realm_name": "gold",
    "realm_epoch": 2
}


# radosgw-admin period commit
2016-08-16 17:51:22.324368 7f8562da6900  0 error read_lastest_epoch .rgw.root:periods.8d0d4955-592c-48b5-93d1-3fa1cec17579.latest_epoch
2016-08-16 17:51:22.347375 7f8562da6900  1 Set the period's master zonegroup default as the default
{
    "id": "8d0d4955-592c-48b5-93d1-3fa1cec17579",
    "epoch": 1,
    "predecessor_uuid": "f8fafae9-b6d2-41f6-b7aa-7b03fea57bfb",
    "sync_status": [
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        "",
        ""
    ],
    "period_map": {
        "id": "8d0d4955-592c-48b5-93d1-3fa1cec17579",
        "zonegroups": [
            {
                "id": "default",
                "name": "default",
                "api_name": "CENSORED",
                "is_master": "true",
                "endpoints": [
                    "https:\/\/CENSORED-1.EXAMPLE.COM",
                    "https:\/\/CENSORED-2.EXAMPLE.COM"
                ],
                "hostnames": [
                    "CENSORED-1.EXAMPLE.COM",
                    "CENSORED-2.EXAMPLE.COM"
                ],
                "hostnames_s3website": [],
                "master_zone": "default",
                "zones": [
                    {
                        "id": "default",
                        "name": "default",
                        "endpoints": [],
                        "log_meta": "true",
                        "log_data": "false",
                        "bucket_index_max_shards": 31,
                        "read_only": "false"
                    }
                ],
                "placement_targets": [
                    {
                        "name": "default-placement",
                        "tags": []
                    }
                ],
                "default_placement": "default-placement",
                "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103"
            }
        ],
        "short_zone_ids": [
            {
                "key": "default",
                "val": 2610307010
            }
        ]
    },
    "master_zonegroup": "default",
    "master_zone": "default",
    "period_config": {
        "bucket_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "max_size_kb": -1,
            "max_objects": -1
        }
    },
    "realm_id": "1ac4fd8d-9e77-4fd2-ad54-b591f1734103",
    "realm_name": "gold",
    "realm_epoch": 2
}


Top

SSA: Ixnay on txt msg reqmnt 4 e-acct, sry

Postby BrianKrebs via Krebs on Security »

The U.S. Social Security Administration says it is reversing a newly enacted policy that required a cell phone number from all Americans who wished to manage their retirement benefits at ssa.gov. The move comes after a policy rollout marred by technical difficulties and criticism that the new requirement did little to prevent identity thieves from siphoning benefits from Americans who hadn’t yet created accounts at ssa.gov for themselves.

In an announcement last month, the SSA said all new and existing ‘my Social Security’ account holders would need to provide a cell phone number. The SSA said the numbers would be used to send recipients an 8-digit code via text message that needs to be entered along with a username and password to log in to the site.

But sometime in the past few days, apparently, the SSA decided to rescind the cell phone rule.

“We removed the requirement to use a cell phone to access your account,” the agency noted in a message posted to its mySocial Security portal. “While it’s not mandatory, we encourage those of you who have a text capable cell phone to take advantage of this optional extra security. We continue to pursue more options beyond cell phone texting.”

Hopefully, those options will include using the U.S. Mail to send Americans a one-time code that needs to be entered at the SSA’s Web site to complete the sign-up process. I should note that the SSA is already mailing out paper letters via snail mail to Americans who’ve signed up for an SSA account online; they’re just not using that mailing to securely complete the signup and authentication process.

Here’s a redacted letter that a friend of mine received and shared the other day after signing up for an account online. It merely explains what the agency already explained about the texting policy via its Web site.

A letter that the Social Security Administration sends out via the U.S. Mail for every American who signs up to manage their benefits at ssa.gov.
The SSA does still offer the text message feature as part of what it calls “extra security” options. These extra options by the way do include the sending users a special code via the U.S. Mail that has to be entered on the agency’s site to complete the signup process. If you choose to enable extra security, the SSA will then ask you for:

  • The last eight digits of your Visa, MasterCard, or Discover credit card;
  • Information from your W2 tax form;
  • Information from a 1040 Schedule SE (self-employment) tax form; or
  • Your direct deposit amount, if you receive Social Security benefits.
Sadly, crooks won’t go through the more rigorous signup process — they’ll choose the option that requires less information. That means it is still relatively easy for thieves to create an account in the name of Americans who have not already created one for themselves. All one would need is the target’s name, date of birth, Social Security number, residential address, and phone number. This personal data can be bought for roughly $3-$4 from a variety of cybercrime shops online.

What else does the SSA require to prove you’re you? Assuming you can buy or supply the above personal data, the agency relays four multiple-guess, so-called “knowledge-based authentication” or KBA questions from credit bureau Equifax. In practice, many of these KBA questions — such as previous address, loan amounts and dates — can be successfully enumerated with random guessing.  What’s more, very often the answers to these questions can be found by consulting free online services, such as Zillow and Facebook.

In September 2013, I warned that SSA and financial institutions were tracking a rise in cases wherein identity thieves register an account at the SSA’s portal using a retiree’s personal information and have the victim’s benefits diverted to prepaid debit cards that the crooks control. Unfortunately, because the SSA’s new security features are optional, they do little to block crooks from hijacking SSA benefit payments from retirees.

Because it’s possible to create just one my Social Security account per Social Security number, registering an account on the portal is one basic way that Americans can avoid becoming victims of this scam.

In addition to the SSA’s optional security measures, Americans can further block ID thieves by placing a security freeze on their credit files with the major credit bureaus. Readers who have taken my ceaseless advice to freeze their credit will need to temporarily thaw the freeze in order to complete the process of creating an account at ssa.gov. Looked at another way, having a freeze in place blocks ID thieves from fraudulently creating an account in your name and potentially diverting your government benefits.

Alternatively, citizens can block online access to their Social Security account. Instructions for doing that are here.
Top

Whatsapp-Medien, der Speedport-Hybrid und dessen interner DHCP-Server

Postby Dennis Klein via DieTa.Photo - Medium »



Seit gut 1 1/2 Jahren nutze ich die Brückentechnologie “Hybrid” von der Deutschen Telekom. Dabei werden, um es mal vereinfacht zu…

Continue reading on DieTa.Photo »
Top

Creating Logos for u-boot images

Postby Warner Losh via Warner's Random Hacking Blog »

The Default Logo: Tux

By default, Das U-boot uses a penguin logo when it first starts up. This default looks something like this

While it's cool to have this for Linux users, FreeBSD users would like to see something more relevant. I recently got a pcDuino 3 board that I wanted to get FreeBSD running on. When I saw Tux still greeting me, I knew I had to do something. If nothing else, we should be branding the images made by the project with project logos and not the default which advertises a competitor.

The Quest

So, I set off on a quest to find the logo that would be best. It turns out to be not as simple a question as I thought jumping into this as I thought.

Logo vs Mascot

Traditionally, FreeBSD has had both the logo and the mascot as part of its boot sequence. The FreeBSD daemon that was used was based on artwork from the Walnut Creek CDROM which in turn was based on artwork drawn for Kirk McKusick by Lassiter. I realized that I'd have to do both. I'd make the logo the default, but also make it possible to have the mascot. While the Lassiter image appears to be the official mascot of the project, the Walnut Creek CDROM image is more widely viewed as the mascot of the FreeBSD project, so I had to select which one to use, or add yet another option.

Finding Good Artwork

The needs of u-boot is simple. Generally, you have an 80x80 image that's splashed up on the screen. While there is some wiggle room for the size of the icon, irregular sized icons just look sloppy in comparison to the default (there's several in the u-boot distribution to choose from, so I tried each one and was left dissatisfied each time).

A few web searches later, I found the best three examples to work from that I could: one with the FreeBSD logo, one with the Lassiter image, and a decent one of the Walnut Creek CDROM cd inserts and various books on FreeBSD (the older image from the 2.0 CDROM, not the newer one with daemon walking out of the CD that was used after).

The Lassiter image was by far the worst of the lot, but it was the best I could find. It proved too difficult to work with, so I eliminated it from my work. The logo and the Walnut Creek daemons would have to do.

Creating BMP images

Turns out this is harder than I would have thought.

To do the FreeBSD-associated daemon, I grabbed a copy from wikipedia's BSD daemon article and did the following:
convert freebsd-daemon.jpg -bordercolor white -channel RGBA -fuzz 20% -fill black -floodfill +0+0 white -resize 80x80\! -colors 200 -alpha off -type palette -compress none freebsd-daemon-1.bmp
To do the FreeBSD logo, I grabbed a copy from the FreeBSD web site and did the following:


convert logo-full.png -crop 172x172+2+2\! -resize 80x80 -colors 200 -alpha off -type palette -compress none -transparent-color black logo-full.bmp


This astute observer will notice a few things here. First, both images were 80x80. That's the default size. The u-boot tool, even with my fixes, only works with widths that are an even multiple of 4. I did 200 colors, but the limit is 240 (256 - 16).  Due to the way that uboot encodes the images, more than around 100 colors isn't going to have a big impact for either of these images (it takes the upper nibble from R G and B value that, and only that, so nuanced differences in colors don't matter). There's likely some fancy mode to optimize color generation in ImageMagick (where the convert program comes from), but I stopped before finding it.

Fixing U-Boot to have it join the 21st century

Turns out the bmp_logo utility that comes with u-boot has some serious limitations. First, it won't detect when you have a width that isn't a multiple of 4, and will generate a bad file instead that you won't discover is bad until you boot the box. Next, it doesn't check to see if the bmp is a compressed one or not with the same result. Ditto for number of colors. Same result. Those are all annoying, but the worst thing of all is that it won't handle any BMP that's newer than Windows 95. The BMP format has a field in a header that tells it how big the image hader is. bmp_logo, as distributed, assumes this length (40), but that only works for win95 and older (but not too old, super-antient BMPs likely would fail too). Any modern tool will generate the newer format (like ImageMagick does).

I've fixed the bmp_logo program locally, and merged a copy of the diffs into FreeBSD's repo for the sysutils/u-boot-olimex-a20-som-evb port (so all a20 and newer allwinner ports). I'm working to get this upstreamed.

The Results

Logo

Here's a slightly blurry shot of the logo I settled on. https://people.freebsd.org/~imp/20160814_104146.jpg

[update]
http://people.freebsd.org/~imp/20160815_234153.jpg uses the newest FreeBSD Foundation recommended logo...

The Daemon Formerly Known as Chuckie

Here's a blurry shot of the Walnut Creek daemon.  https://people.freebsd.org/~imp/20160814_124703.jpg

u-boot changes

I've created patches for the A20 Allwinnner ports. They will be committed shortly. I'll also be working to get these upstream into u-boot.
Top

vc4 status update for 2016-08-15: DSI panel, Raspbian updates, and docs

Postby Eric Anholt via anholt's lj »

Last week I mostly worked on getting the upstream work I and others have done into downstream Raspbian (most of that time unfortunately in setting up another Raspbian development environment, after yet another SD card failed).

However, the most exciting thing for most users is that with the merge of the rpi-4.4.y-dsi-stub-squash branch, the DSI display should now come up by default with the open source driver.  This is unfortunately not a full upstreamable DSI driver, because the closed-source firmware is getting in the way of Linux by stealing our interrupts and then talking to the hardware behind our backs.  To work around the firmware, I never talk to the DSI hardware, and we just replace the HVS display plane configuration on the DSI's output pipe.  This means your display backlight is always on and the DSI link is always running, but better that than no display.

I also transferred the wiki I had made for VC4 over to github.  In doing so, I was pleasantly surprised at how much documentation I wanted to write once I got off of the awful wiki software at freedesktop.  You can find more information on VC4 at my mesa and linux trees.

(Side note, wikis on github are interesting.  When you make your fork, you inherit the wiki of whoever you fork from, and you can do PRs back to their wiki similarly to how you would for the main repo.  So my linux tree has Raspberry Pi's wiki too, and I'm wondering if I want to move all of my wiki over to their tree.  I'm not sure.)

Is there anything that people think should be documented for the vc4 project that isn't there?
Top

Visa Alert and Update on the Oracle Breach

Postby BrianKrebs via Krebs on Security »

Credit card industry giant Visa on Friday issued a security alert warning companies using point-of-sale devices made by Oracle‘s MICROS retail unit to double-check the machines for malicious software or unusual network activity, and to change passwords on the devices. Visa also published a list of Internet addresses that may have been involved in the Oracle breach and are thought to be closely tied to an Eastern European organized cybercrime gang.



The Visa alert is the first substantive document that tries to help explain what malware and which malefactors might have hit Oracle — and by extension many of Oracle’s customers — since KrebsOnSecurity broke news of the breach on Aug. 8. That story cited sources close to the investigation saying hackers had broken into hundreds of servers at Oracle’s retail division, and had completely compromised Oracle’s main online support portal for MICROS customers.

MICROS is among the top three point-of-sale vendors globally. Oracle’s MICROS division sells point-of-sale systems used at more than 330,000 cash registers worldwide. When Oracle bought MICROS in 2014, the company said MICROS’s systems were deployed at some 200,000+ food and beverage outlets, 100,000+ retail sites, and more than 30,000 hotels.

In short, tens of millions of credit cards are swiped at MICROS terminals monthly, and a breach involving the theft of credentials that might have granted remote access to even just a small percentage of those systems is potentially a big and costly problem for all involved.

So far, however, most MICROS customers are left scratching their heads for answers. A frequently asked questions bulletin (PDF) Oracle also released last Monday held little useful information. Oracle issued the same cryptic response to everyone who asked for particulars about how far the breach extended. “Oracle has detected and addressed malicious code in certain legacy MICROS systems.”

Oracle also urged MICROS customers to change their passwords, and said “we also recommend that you change the password for any account that was used by a MICROS representative to access your on-premises systems.”

One of two documents Oracle sent to MICROS customers and the sum total of information the company has released so far about the breach.
Some technology and fraud experts, including Gartner Analyst Avivah Litan, read that statement highlighted in yellow above as an acknowledgement by Oracle that hackers may have abused credentials gained in the MICROS portal breach to plant malicious code on the point-of-sale devices run by an unknown number of MICROS customers.

“This [incident] could explain a lot about the source of some of these retail and merchant point-of-sale hacks that nobody has been able to definitively tie to any one point-of-sale services provider,” Litan told me last week. “I’d say there’s a big chance that the hackers in this case found a way to get remote access” to MICROS customers’ on-premises point-of-sale devices.”

Clearly, Visa is concerned about this possibility as well.

INDICATORS OF COMPROMISE

In my original story about the breach, I wasn’t able to reveal all the data I’d gathered about the apparent source of the attacks and attackers. A key source in that story asked that I temporarily delay publishing certain details of the investigation, specifically those known as indicators of compromise (IOCs). Basically, IOCs are list of suspect Internet addresses, domain names, filenames and other curious digital clues that are thought to connect the victim with its attacker.

I’ve been inundated all week with calls and emails from security experts asking for that very data, but sharing it wasn’t my call. That is, until yesterday (8/12/16), when Visa published a “merchant communication alert” to some customers. In that alert (PDF), Visa published IOCs that may be connected with the intrusion. These IOCs could be extremely useful to MICROS customers because the presence of Internet traffic to and from these online destinations would strongly suggest the organization’s point-of-sale systems may be similarly compromised.

Some of the addresses on this list from Visa are known to be associated with the Carbanak Gang, a group of Eastern European hackers that Russian security firm Kaspersky Lab estimates has stolen more than $1 billion from banks and retailers. Here’s the IOCs list from the alert Visa pushed out Friday:

Visa warned merchants to check their systems for any communications to and from these Internet addresses and domain names associated with a Russian organized cybercrime gang called “Carbanak.”
Thankfully, since at least one of the addresses listed above (192.169.82.86) matched what’s on my source’s list, the source agreed to let me publish the entire thing. Here it is. I checked my source’s list and found at least five Internet addresses that were seen in both the Oracle attack and in a Sept. 2015 writeup about Carbanak by ESET Security, a Slovakian antivirus and security company. [NB: If you are unskilled at safely visiting malicious Web sites and/or handling malware, it’s probably best not to visit the addresses in the above-linked list.]

Visa also mentioned a specific POS-malware threat in its alert called “MalumPOS.” According to researchers at Trend Micro, MalumPOS is malware designed to target point-of-sale systems in hotels and related industries. In fact, Trend found that MalumPOS is set up to collect data specifically from point-of-sale systems running on Oracle’s MICROS platform.

It should come as no surprise then that many of Oracle’s biggest customers in the hospitality industry are starting to make noise, accusing Oracle of holding back key information that could help MICROS-based companies stop and clean up breaches involving malware and stolen customer credit card data.

“Oracle’s silence has been deafening,” said Michael Blake, chief executive officer at HTNG, a trade association for hotels and technology. “They are still grappling and trying to answer questions on the extent of the breach. Oracle has been invited to the last three [industry] calls this week and they are still going about trying to reach each customer individually and in the process of doing so they have done nothing but given the lame advice of changing passwords.”

The hospitality industry has been particularly hard hit by point-of-sale compromises over the past two years. Last month, KrebsOnSecurity broke the news of a breach at Kimpton Hotels (Kimpton appears to run MICROS products, but the company declined to answer questions for this story).

Kimpton joins a long list of hotel brands that have acknowledged card breaches over the last year, including Trump Hotels (twice), Hilton, Mandarin Oriental, and White Lodging (twice), Starwood Hotels and Hyatt. In many of those incidents, thieves had planted malicious software on the point-of-sale devices at restaurants and bars inside of the hotel chains. And, no doubt, many of those cash registers were run on MICROS systems.

If Oracle doesn’t exactly know which — if any — of its MICROS customers had malware on their point-of-sale systems as a result of the breach, it may be because the network intruders didn’t have any reason to interact with Oracle’s customers via the MICROS portal after stealing usernames and passwords that would allow them to remotely access customer on-premises systems. In theory, at that point the fraudsters could have bypassed Oracle altogether from then on.

BREACHED BY MULTIPLE ACTORS?

Another possibly interesting development in the Oracle breach story: There are indications that Oracle may have been breached by more than one cybercrime group. Or at least handed off from one to the other.

Late this week, Thomas Fox-Brewster at Forbes published a story noting that MICROS was just one of at least five point-of-sale companies that were recently hacked by a guy who — from an exhaustive review of his online chats — appears to have just sat himself down one day and decided to hack a bunch of point-of-sale companies.

Forbes quoted my old friend Alex Holden of Hold Security saying he had evidence that hackers had breached at least 10 payment companies, and the story focuses on getting confirmation from the various other providers apparently breached by the same cybercriminal actor.

Holden showed me multiple pages worth of chat logs between two individuals on a cybercrime forum [full disclosure: Holden’s company lists me as an adviser, but I accept no compensation for that role, and he ignores most of my advice].

The discussion between the two hackers begins around July 15, 2016, and goes on for more than a week. In it, the two hackers have been introduced to one another through a mutual, trusted contact. For a while, all they discuss is whether the seller can be trusted to deliver the Oracle MICROS database and control over the Oracle MICROS customer ticketing portal.

In the end, the buyer is convinced by what he sees and agrees to pay the bitcoin equivalent of roughly USD $13,000 for access to Oracle’s MICROS portal, as well as a handful of other point-of-sale Web sites. The buyer’s bitcoin wallet and the associated transactions can be seen here.

A screen shot shared by one of the hackers involved in compromising Oracle’s MICROS support portal. This screen shot was taken of a similar Web shell the hackers placed on the Web site of another POS provider (this is not the shell that was on Oracle).
According to the chat log, the hacker broke in by exploiting a file-upload function built into the MICROS customer support portal. From there the attackers were able to upload an attack tool known as a “WSO Web Shell.” This is a crude but effective text-based control panel that helps the attacker install additional attack tools to harvest data from the compromised Web server (see screen shot above). The beauty of a Web shell is that the attacker can control the infected site using nothing more than a Web browser, using nothing more than a hidden login page and a password that only he knows.

The two hackers discussed and both viewed more than a half-dozen files that were apparently left behind on the MICROS portal by the WSO shell they uploaded in mid-July (most of the malicious files ended in the file extension “wso.aspx”). The chat logs show the pair of miscreants proceeding to target another 9 online payment providers or point-of-sale vendors.

Some of those companies were quoted in the Forbes piece having acknowledged a breach similar to the Web shell attack at Oracle. But none of them have anywhere near the size of Oracle’s MICROS customer base.

GOOD HOSPITALITY, OR SWEPT UNDER THE RUG?

Oracle maintains in its FAQ (PDF) about the MICROS attack that “Oracle’s Corporate network and Oracle’s other cloud and service offerings were not impacted.” But a confidential source within Oracle’s Hospitality Division told KrebsOnSecurity that the breach first started in one of Oracle’s major point-of-sale data centers — specifically the company’s large data center in Manassas, Va.

According to my source, that particular center helps large Oracle hospitality industry clients manage their fleets of MICROS point-of-sale devices.

“Initially, the customer’s network and the internal Oracle network were on the same network,” said my source, who spoke under condition of anonymity because he did not have permission from his employer to speak on the record. “The networking team did a network segmentation of these two networks — ironically for security purposes. However, it seems as if what they have done actually allowed access from the Russian Cybercrime group.”

My source said that in mid-July 2016 Oracle sent out an email alert to employees of its hospitality division that they had to re-image their laptops without backing anything up.

“All of the files and software that were on an employee’s computer were deleted, which was crippling to business operations,” my source recalled. “Project management lost all their schedules, deployment teams lost all the software that they use to install on customer sites. Oracle did not tell the employees in this email that they got hacked but just to re-image everything with no backups. It seems as if Oracle did a pretty good job sweeping this incident under the rug. Most employees don’t know about the hack and it hasn’t been a huge deal to the customers. However, it is estimated that this cost them billions, so it is a really major breach.”

I sent Oracle a litany of questions based on the above, but a spokesperson for the company said Oracle would comment on none of it.
Top

The Open Source of Photography — Unsplash

Postby Dennis Klein via DieTa.Photo - Medium »



I like Open Source Software. I use it every day, at work, and also in my free time. It’s running on my server in the basement and powers…

Continue reading on DieTa.Photo »
Top

FreeBSD 11.0-RC1 Available

Postby Webmaster Team via FreeBSD News Flash »

The first RC build for the FreeBSD 11.0 release cycle is now available. ISO images for the amd64, armv6, i386, aarch64, powerpc, powerpc64 and sparc64 architectures are available on most of our FreeBSD mirror sites.
Top

Bottle, Glasses and a White Rabbit

Postby Dennis Klein via DieTa.Photo - Medium »



including some “Behind the scenes” photos

Continue reading on DieTa.Photo »
Top

Road Warriors: Beware of ‘Video Jacking’

Postby BrianKrebs via Krebs on Security »

A little-known feature of many modern smartphones is their ability to duplicate video on the device’s screen so that it also shows up on a much larger display — like a TV. However, new research shows that this feature may quietly expose users to a simple and cheap new form of digital eavesdropping.

Dubbed “video jacking” by its masterminds, the attack uses custom electronics hidden inside what appears to be a USB charging station. As soon as you connect a vulnerable phone to the appropriate USB charging cord, the spy machine splits the phone’s video display and records a video of everything you tap, type or view on it as long as it’s plugged in — including PINs, passwords, account numbers, emails, texts, pictures and videos.

Some of the equipment used in the “video jacking” demonstration at the DEF CON security conference last week in Las Vegas. Source: Brian Markus.
[Click here if you’re the TL;DR type and just want to know if your phone is at risk from this attack.]

Demonstrations of this simple but effective mobile spying technique were on full display at the DEF CON security conference in Las Vegas last week. I was busy chasing a story at DEF CON unrelated to the conference this year, so I missed many people and talks that I wanted to see. But I’m glad I caught up with the team behind DEF CON’s annual and infamous “Wall of Sheep,” a public shaming exercise aimed at educating people about the dangers of sending email and other plain text online communications over open wireless networks.

Brian Markus, co-founder and chief executive officer for Aries Security, said he and fellow researchers Joseph Mlodzianowski and Robert Rowley came up with the idea for video jacking when they were brainstorming about ways to expand on their “juice jacking” experiments at DEF CON in 2011.

“Juice jacking” refers to the ability to hijack stored data when the user unwittingly plugs his phone into a custom USB charging station filled with computers that are ready to suck down and record said data (both Android and iOS phones now ask users whether they trust the computer before allowing data transfers).

In contrast, video jacking lets the attacker record every key and finger stroke the user makes on the phone, so that the owner of the evil charging station can later replay the videos and see any numbers or keys pressed on the smart phone.

That’s because those numbers or keys will be raised briefly on the victim’s screen with each key press. Here’s an example: While the user may have enabled a special PIN that needs to be entered before the phone unlocks to the home screen, this method captures even that PIN as long as the device is vulnerable and plugged in before the phone is unlocked.

GREAT. IS MY PHONE VULNERABLE?

Most of the phones vulnerable to video jacking are Android or other HDMI-ready smartphones from Asus, Blackberry, HTC, LG, Samsung, and ZTE. This page of HDMI enabled smartphones at phonerated.com should not be considered all-inclusive. Here’s another list. When in doubt, search online for your phone’s make and model to find out if it is HDMI or MHL ready.

Video jacking is a problem for users of HDMI-ready phones mainly because it’s very difficult to tell a USB cord that merely charges the phone versus one that also taps the phone’s video-out capability. Also, there’s generally no warning on the phone to alert the user that the device’s video is being piped to another source, Markus said.

“All of those phones have an HDMI access feature that is turned on by default,” he said. “A few HDMI-ready phones will briefly flash something like ‘HDMI Connected’ whenever they’re plugged into a power connection that is also drawing on the HDMI feature, but most will display no warning at all. This worked on all the phones we tested with no prompting.”

Both Markus and Rowley said they did not test the attack against Apple iPhones prior to DEF CON, but today Markus said he tested it at an Apple store and the video of the iPhone 6’s home screen popped up on the display in the store without any prompt. Getting it to work on the display required a special lightning digital AV adapter from Apple, which could easily be hidden inside an evil charging station and fed an extension adapter and then a regular lightning cable in front of that.



WHAT’S A FAKE CHARGING STATION?

Markus had to explain to curious DEF CON attendees who wandered near the Wall of Sheep this year exactly what would happen if they plugged their phone into his phony charging station. As you can imagine, not a ton of people volunteered but there were enough to prove a point, Markus said.

The demonstration unit that Markus and his team showed at DEF CON (pictured above) was fairly crude. Behind a $40 monitor purchased at a local Vegas pawn shop is a simple device that takes HDMI output from a video splitter. That splitter is connected to two micro USB to HDMI cables that are cheaply available in electronics stores.

Those two cords were connected to standard USB charging cables for mobiles — including the universal micro USB to HDMI adapter (a.k.a. Mobile High Definition Link or MHL connector), and a slimport HDMI adapter. Both look very similar to standard USB charging cables. The raw video files are recorded by a simple inline recording device to a small USB storage device taped to the back of the monitor.

Markus said the entire rig (minus the TV monitor) cost about $220, and that the parts could be bought at hundreds of places online.

Although it may be difficult to tell the difference at this angle, the Mobile High Definition Link (MHL) USB connector on the left has a set of six extra pins that enable it to read HDMI video and whatever is being viewed on the user’s screen. Both cords will charge the same phone.
SHOULD YOU CARE?

My take on video jacking? It’s an interesting and very real threat — particularly if you own an HDMI ready phone and are in the habit of connecting it to any old USB port. Do I consider it likely that any of us will have to worry about this in real life? The answer may have a lot to do with what line of work you’re in and how paranoid you are, but it doesn’t strike me as very likely that most mere mortals would have reason to worry about video jacking.

On the other hand, it would be a fairly cheap and reasonably effective (if random) way to gather secrets from a group of otherwise unsuspecting people in a specific location, such as a hotel, airport, pub, or even a workplace.

An evil mobile charging station would be far more powerful when paired with a camera (hidden or not) trained on the charger. Imagine how much data one could hoover up with a fake charging station used to gather intellectual property or trade secrets from, say….attendees of a niche trade show or convention.

Now that I think about it, since access to electric power is not a constraint with these fake charging stations, there’s no reason it couldn’t just beam all of its video wirelessly. That way, the people who planted the spying equipment could retrieve or record the victim videos in real time and never have to return to the scene of the crime to collect any of it. Okay, I’ll stop now.

What can vulnerable users do to protect themselves from video jacking?

Hopefully, your phone came with a 2-prong charging cord that plugs straight into a standard wall jack. If not, look into using a USB phone charger adapter that has a regular AC/DC power plug on one end and a female USB port on the other (just make sure you don’t buy this keystroke logger disguised as a USB phone charger). Carry an extra charging dock for your mobile device when you travel.

Also, check the settings of your mobile and see if it allows you to disable screen mirroring. Note that even if you do this, the mirroring capability might not actually turn off.

What should mobile device makers do to minimize the threat from video jacking? 

“The problem here is that device manufacturers continue to add features and not give us prompting,” Markus said. “With this feature, it automatically connects no matter what. HDMI-out should be off by default, and if turned on it should require prompting the user.”

Update: 4:52 p.m. ET: Updated paragraph about Apple iPhones to clarify that this same attack works against the latest iPhone 6.
Top

A little self-built photo studio

Postby Dennis Klein via DieTa.Photo - Medium »



I love to experiment with light and shadow. This whole process of trying out things to get to a great photo.

Continue reading on DieTa.Photo »
Top

Moved to Medium.com

Postby Dennis Klein via DieTa.Photo - Medium »

Back in 1996, when my first PC (guess it was a 486 or Pentium 100) went online via analog modem and 28kbit/s, I was very interested in…

Continue reading on DieTa.Photo »
Top