Just to let you know...

sossego

Retired from the forums
GCC has been carrying around a few root-kits in their repositories. I had one for a short while before it became active. When my system started acting up, I located it by looking for discrepancies that came by gcc-4.7-*update.tar.gz. These files may also have numbered dates in the name. So, I decided to read it in SciTE. Lo and behold if the 733t15t 4553mb73r5 (elitist assemblers) weren't back in mass talking between assembly data.
  1. There are plain messages in the text. Read and pick them up because they leave trails.
  2. The thing self destructs after you read it. So, if you are going to decode, do it fast and then copy-paste it to another part to read.
  3. GCC by itself has patchy behavior which is being exposed en masse by Clang.
  4. Do yourself a favor and destroy the original.
  5. Some root-kit systems work with two parts. I'm guessing a sender and a receiver. Without both parts, it becomes useless.
 
A quick spin of $SEARCH_ENGINE did not produce anything on this matter. Do you have more information about this?
 
Look at the size of the files in the GCC repositories and think, "Why is a GCC update only 1 MB in size?" If that doesn't convince you, then try to untar the file and see what happens. I have no reason to throw a bunch of bullshit on a security topic of this level. You've been given a public heads up on this, learn to follow it.
 
sossego said:
Look at the size of the files in the GCC repositories and think, "Why is a GCC update only 1MB in size?"

Which file, exactly? Was it for a port, and did the checksums match? Have you reported it to the GCC people, or to the FreeBSD porters? How can a FreeBSD user verify if a file is infected? Is there a security notice about this?

If that doesn't convince you, then try to untar the file and see what happens.

I'd rather not mess with a dangerous file without knowing what to expect. What does happen?

I have no reason to throw a bunch of bullshit on a security topic of this level.
You've been given a public heads up on this, learn to follow it.

Sorry, to use this, we need more details.
 
wblock@ said:
Which file, exactly?
The GCC 4.7 updated file.
Was it for a port, and did the checksums match? Have you reported it to the GCC people, or to the FreeBSD porters? How can a FreeBSD user verify if a file is infected? Is there a security notice about this?
It was from a port download. I did not check or verify the checksums. I would rather make this public so that people will know. How can there be a security notice if no one bothers to check the repositories for inconsistencies? Have you thought of asking the porters to be more diligent when adding links for downloads? Have you thought of asking the security team to have more people to check the consistency of the files that the porters used? I believe the answers to both of those questions is no. Did I think of reporting what I saw to enough people and publicly so that others would be aware? Oh shit yes I did.

I'd rather not mess with a dangerous file without knowing what to expect. What does happen?
It becomes active. It also self destructs and contains multiple conversations and references.

Sorry, to use this, we need more details.
Those are the details. Someone got sloppy and ended up losing privileges to another. Remember that the FreeBSD files and all were also compromised by one person losing control. Had that person caught what happened in time, none of that situation would have been true.
@wblock@, everyone does not have an eidetic memory when it comes to recalling an accident. You want details and I am concerned with getting the people out of the car and letting you know it.

Take it or leave it. I'm not into jerking people around for a few laughs.
 
Last edited by a moderator:
You're giving conclusions, but I'm asking for evidence so I can draw my own conclusions. I'd be happy to verify a problem, but can't find a 1 MB file in lang/gcc47. The distfile is 78 MB, the patch files a few hundred bytes.

People probably aren't going to avoid GCC 4.7 without something more definite.
 
If you could finally point us to the exact file, it's location, size and SHA256 checksum and we might even believe you. Without that information everyone is going to conclude that you're imagining things.

Is it one of the distfiles of the lang/gcc47? Those are really easy to list since there's only one file in distinfo:

Code:
SHA256 (gcc-4.7-20131130.tar.bz2) = 0223a1beb8524b26a7193f4c871222a5f6455058fb2ee5d559f0b7b370a8f44c
SIZE (gcc-4.7-20131130.tar.bz2) = 78837894

Or one of the local patches perhaps:

Code:
/usr/ports/lang/gcc47 % ls -l files 
total 8
-rw-r--r--  1 root  wheel  522 Oct 19 00:49 java-patch-hier
-rw-r--r--  1 root  wheel  266 Oct 19 00:49 patch-libcpp

Those are the only files one could suspect if there's a breach on FreeBSD side of things as you're claiming. If there's a security breach on the site that hosts the distfiles (the upstream for GCC 4.7) then it's a whole another matter.
 
  1. It seems to be a security breach on the GCC hosted sites.
  2. http://www.gmanetwork.com/news/story/337833/scitech/technology/beware-of-new-worm-targeting-linux-pcs-symantec
If number two comes from software that is shared with other operating systems, ....

Again, if you/porter/developer/user does not check from where the sources/links are - and that others depend upon you - then you have inadvertently caused a security breach on another system by not checking everything.

@kpa, the file from the repository I had downloaded was not the same size as what you stated.
 
Last edited by a moderator:
What is the file that you downloaded and what was the name of it and where did you download it. URL, full details please. This is getting rediculous with claims of security breaches on unnamed sites, unnamed files that no one can compare themselves to anything.

I did look at the link that you gave but that is only an indication that a site running on Linux could be breached by this malware but where is your evidence that this happened with the site that hosts the GCC distribution files?
 
Here is a list of the currently used GCC "master" sites, taken from /usr/ports/Mk/bsd.sites.mk:

Code:
.if !defined(IGNORE_MASTER_SITE_GCC)
MASTER_SITE_GCC+= \
        ${MASTER_SITE_SOURCEWARE:S,%SUBDIR%,gcc/&,} \
        ftp://gcc.gnu.org/pub/gcc/%SUBDIR%/ \
        ftp://mirrors.laffeycomputer.com/pub/gcc.gnu.org/pub/gcc/%SUBDIR%/ \
        ftp://ftp.lip6.fr/pub/gcc/%SUBDIR%/ \
        ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/%SUBDIR%/ \
        ftp://ftp.uvsq.fr/pub/gcc/%SUBDIR%/ \
        ftp://ftp.gwdg.de/pub/misc/gcc/%SUBDIR%/ \
        ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/%SUBDIR%/ \
        ftp://ftp.iij.ad.jp/pub/gnu/gnu/gcc/%SUBDIR%/ \
        ftp://ftp.dti.ad.jp/pub/lang/gcc/%SUBDIR%/ \
        ftp://ftp.nluug.nl/mirror/languages/gcc/%SUBDIR%/ \
        ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/%SUBDIR%/ \
        ftp://ftp.ntua.gr/pub/gnu/gcc/%SUBDIR%/ \
        ftp://mirror.aarnet.edu.au/pub/gnu/gcc/%SUBDIR%/
.endif

Is your site among those?
 
[WB: I've taken the liberty of replacing the obscenities with random baby names.]

I told you the Uzimaing file name.
I told you the file size.
I told you what it was.
I told you what was written on it.

If someone is shooting at you, are you going to be Jabbaringly stupid enough to ask them what kind of gun they are using? Farley no you wouldn't. You would run for your life and say, "Hey, there's a crazy Madison with a gun shooting it. Run for your Panchaliing lives!"

You were told what to look for.

Let me rephrase it in big red letters for you.

[WB: big red letters removed to protect those with weak dispositions.]

If anyone has a gcc.tar.gz or gcc.tar.bz of the 4.7 series and it is only one megabyte in size, it's a rootkit/worm/trojan. Eliminate it. End of story.
 
You might want to reconsider the tone of your reply before the mods make short work of it. Making such claims of a security breach is serious business and you better be ready to answer some tough questions from those who know more about security than you do. It's all for separating truths from falsehoods so that in case there is a real security breach it can be properly reported forward. The Internet is full of reports like these of well known sites spreading viruses and malware but almost none of them are worth a damn because they provide no good evidence it's equally likely that the source of the infection is a local one, for example a hacked proxy.

One other thing: Have you even thought about the size of your audience when you write a report of a security breach here? These forums are constantly indexed by Google and Bing bots so anyone searching for reports of security breaches will find your report quite fast. Think of what that means.
 
Had any of you paid attention to the fact that I reported what I remembered to the public and did not hide it instead of deliberately and outright accusing me of being a liar, I would not have become infuriated.
 
sossego said:
Had any of you paid attention to the fact that I reported what I remembered to the public and did not hide it instead of deliberately and outright accusing me of being a liar, I would not have become infuriated.
Point of order: nobody has accused you of lying. But when you post a serious warning like this one, that could have significant consequences, you really cannot fault people for wanting to verify the problem and even see if they can be of help. There's no need to get all defensive.
 
Nobody is calling you a liar but we do require some form of verification, especially when dealing with issues like this. Just crying wolf doesn't help anyone.
 
Well, I just checked the Dutch mirror site to look for something odd and went over all 25+ snapshot directories for GCC 4.7.x but I couldn't find any file which matched the description. Unless you can provide a source I'm afraid that this report isn't of much use in its current state.

The only oddity I did come across was when looking at the Japanese mirror site. According to the Makefile in the lang/gcc47 port directory it'll use a specific subdirectory on the master site:

Code:
MASTER_SITES=   ${MASTER_SITE_GCC}
MASTER_SITE_SUBDIR=     snapshots/${DISTVERSION}
The problem here is that the Japanese mirror which I listed above only provides the release versions and no snapshots. Ergo no snapshots directory so when that mirror is used I suspect things to fail. Speaking of which; this French mirror also doesn't seem to be carrying snapshots.

All mirrors do carry files which might match the 1Mb 1 MB filesize requirements:

Code:
diffs 		27-3-2013 	0:00:00
File:gcc-4.7.0.tar.bz2 	80585 KB 	22-3-2012 	0:00:00
File:gcc-4.7.0.tar.gz 	103618 KB 	22-3-2012 	0:00:00
File:md5.sum 	1 KB 	22-3-2012 	0:00:00
I'm hinting at the gcc-4.7.0.tar.gz file here of course. But I have a very hard time believing that this file could be compromised.

Apart from those two weird mirror sites I don't see a problem with the GCC repositories in their current state (note that I didn't go over the whole lot, only the Dutch mirror and checked its state against some other randomly picked mirrors).
 
My apologies. I was thinking more along the lines of giving a warning and not on logging all the information.
 
I would like to believe you, but I need documented evidence.

How do we reproduce this issue?
 
sossego said:
I was thinking more along the lines of giving a warning and not on logging all the information.
That's not a problem but think of it this way, if I yell "Watch out for that bus!", you would like to know where that bus is coming from before you start running. Just so you run away from it instead of towards it. Same thing here, if you see something that doesn't seem right then by all means tell us but do tell us where to look. If only to verify that you're not hunting ghosts and there's really something fishy going on.
 
Okay, thanks.

What I had noticed was a download from a mirror - forgive me for not remembering exactly which one - of a gcc-4.7 2013? update. As I had stated earlier, it was around 1 MB in size. A second error was that a value of 65,535 was attempted to be passed to a library. The other thing was that /bin/ had to be partially rebuilt. The file type was of the tar.gz format in name only.
 
Ports check the size and checksum of a downloaded file and will stop if they don't match. Those can be faked, but it's not easy. lang/gcc47 only lists the one 75 MB distfile, but it could have been part of a dependency.
 
Back
Top